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ABSTRACT 


There are many efforts underway focused on resolving the system and software 
interoperability problems within the Department of Defense. While several of these efforts are 
attempting to attack this issue using new technologies and standardization, experience suggests 
most of these interoperability problems are caused by deficiencies in the way we define and 
capture interoperability requirements within our acquisition processes and policies. In order to 
affect real progress towards department-wide interoperability, it will be necessary to change the 
methods by which interoperability is considered in the acquisition process. 

Many acquisition agents within the DoD suffer from the misconception that technology 
alone can solve their interoperability problems. The reality is that there are many challenges 
within the requirements and planning processes that first must be overcome before technology 
can be effectively applied. Since interoperability requirements are dynamic, and often poorly 
understood before systems are put to use in the field, the requirements and acquisition 
communities must have a flexible and powerful method to communicate in order to overcome 
these challenges. This thesis provides a solution with which the DoD can address these 
fundamental gaps in our acquisition processes, thus creating an environment more conducive to 
software interoperability within our system of systems. 

This thesis will propose a new structured methodology for incorporating the use of 
enterprise architecture techniques into the DoD software acquisition process, to provide a 
means by which interoperability requirements can be captured, defined, and levied at the 
appropriate time in a system’s development. It will discuss the necessary components of these 
architectural models, how these models capture our interoperability needs, and how these 
interoperability needs form the basis for meaningful dialogue between the DoD’s acquisition and 
planning communities. While this methodology is applicable to many domains and functional 
areas, for the purposes of this thesis, the focus will be solely on software systems (including 
systems with embedded software) within the DoD. 
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I. INTRODUCTION 


Interoperability is a state, a condition in which two systems have the ability to exchange 
the information its users need in a meaningful manner. Achieving a state of interoperability 
between two systems requires detailed planning and forethought. Knowing what information is 
required to be exchanged and what formats the systems will support and making the proper 
arrangements for an interface between these systems can be a daunting task. However, it is the 
maintenance of this state of interoperability, which poses the real challenge. Ensuring no 
uncoordinated changes are made to either the systems or the environment that may affect this 
state of interoperability is increasingly difficult in today’s world. Add several systems, systems 
of systems, or families of systems into this equation and the complexity grows exponentially. 

To make two systems interoperable requires several detailed planning steps and multiple 
layers of technical understanding. For example, one needs to know the pieces of information to 
be exchanged, how the two systems will be employed and employed together, the physical 
support necessary to achieve interoperability, the components and capabilities of the two 
systems, and the underlying technologies on which those systems rely. To keep two systems 
interoperable requires a methodology through which changes in the two systems are tracked 
over time, to ensure a constant state of interoperability. 

Several communities of distinct people and needs bring a system to fruition. Users and 
developers are both stakeholders in a system’s development, but both with very different 
perspectives and attitudes towards the system. Furthermore, the people developing a system’s 
requirements and specifications, or the people maintaining a system, may be neither the user, nor 
the developer. Capturing the perspectives and needs of all these communities can be difficult, 
and when trying to meet the needs of multiple systems, each catering to their own sets of 
multiple communities, the problem of interoperability can overwhelm traditional system and 
software development models. 

In recent years, the concepts of using architectures to solve system interoperability 
problems have received much attention. Terms like software architecture, enterprise 
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architecture, operational and system architecture have flooded the engineering community with 

hopes of tackling interoperability troubles. Department of Defense Directive 5000.1 states. 

Interoperability within and among United States forces and U.S. coalition partners is a 
key goal that must be addressed satisfactorily for all Defense systems to that the 
Department of Defense has the ability to conduct joint and combined operations 
successfully... The Department of Defense must have a framework for assessing the 
interrelationships among and interactions between U.S., Allied, and coalition systems. 
Mission area focused, integrated architectures shall be used to characterize these 
interrelationships. This end-to-end approach focuses on mission outcomes and 
provides further understanding of the full range of interoperability issues attendant to 
decisions regarding a single program or system. [15] 

In my capacity as a Command and Control Interoperability Project Officer for the Joint 
Forces Program Office (JFPO), Space and Naval Warfare Systems Command (SPAWAR), 
San Diego, CA, I had the opportunity to work hands-on with several of the major 
interoperability and architecture initiatives that are ongoing throughout the Department of 
Defense. Through this work, I have concluded that the greatest benefit architecture can achieve 
towards interoperability is in the capturing and maintaining of system interoperability 
requirements. Furthermore, while many of the current initiatives have good intentions, they will 
fail to achieve interoperability because they do not recognize two key aspects of the relationship 
between interoperability and architecture: 1) there are many communities, each with distinct 
needs, which must work collectively to create interoperable families of systems; and, 2) a single 
architecture will never meet the needs of all those stakeholders. 

This thesis proposes a methodology for integrating the concepts of enterprise 
architecture into the system and software development cycles, simplifying the currently used 
models into only those objects necessary for achieving the goal of interoperability. It proposes 
a u nif ied repository of architectural data, but with the ability to be viewed in several forms (i.e. 
with the ability to create multiple architectural views), each tailorable to the needs of the different 
stakeholders. The power of this methodology is it provides a mechanism by which functional 
and interoperability requirements are captured, defined, and levied on systems based on how 
they will be employed. This is a dynamic process, which can accept changes to requirements, 
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system environments, and domains; and facilitates the concepts of time-phasing, spiral 
development, requirements vs. capabilities, and operational vs. system needs. 

A. RESEARCH QUESTIONS 

This thesis will answer the following research questions: 

1) Can the use of enterprise architecture throughout the software acquisition lifecycle 
improve the process of defining interoperability requirements for software systems? 

2) How do architectural models allow a software developer to capture the evolving 
interoperability needs of all a system’s stakeholders? 

3) What architectural components are required to support the development and 
maintenance of interoperability requirements? 

4) How does architecture modeling allow multiple software developers to synchronize 
the development of several independent software systems so interoperability is 
continuously achieved? 

B. SCOPE AND LIMITATIONS 

This thesis proposes a methodology for using enterprise architecture techniques to 
capture, define, and levy software interoperability requirements. The author recognizes that 
there are a multitude of other applications of enterprise architectures, even within the 
Department of Defense, that would require different data models, different implementation 
techniques, and different stakeholders. This thesis is lim ited only to those architectural 
requirements necessary for the purposes of capturing, defining, and levying software and system 
interoperability requirements; and, therefore omits--by design--implementation considerations 
lik e technical architecture views and technology standards. 

C. ORGANIZATION 

This thesis is comprised of six main chapters: 

- Chapter I: Introduction 
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- Chapter II: Background/Previous Studies - an outline of some of the many 
enterprise-architecture related efforts ongoing in industry and the Department of Defense 
(DoD). 

- Chapter IE: Software & Interoperability within the DoD -- This chapter introduces the 
reader to the concepts of interoperability, how it fits into the software domain, and how these 
concepts are currently treated within the DoD. It is intended to establish a common framework 
for understanding of the rest of the thesis. 

- Chapter IV: Enterprise Architecture for Software Interoperability -- This chapter 
discusses what enterprise architecture is and shows, through a storyboarded example, how 
proper application of these techniques leads to formation of interoperability requirements. 

- Chapter V: Benefits of the Data-Driven Approach - an explanation of the benefits of 
using a relational database for capturing architectures, as opposed to the more commonly 
applied “picture” approach. 

- Chapter VI: Closing Comments - This chapter provides thesis recommendations and 
conclusions. 
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II. BACKGROUND/PREVIOUS STUDIES 


There are a number of enterprise architecture-related efforts going on throughout the 
Department of Defense and industry. To gain an appreciation for what this thesis represents, 
and how it fits into current activities, I have chosen to outline a few of those efforts on the 
following pages. 

A. DOD ARCHITECTURE FRAMEWORK DOCUMENT [1] 

No discussion of architecture within the DoD could begin properly without an 
explanation of the Department of Defense Architecture Framework Document, also known as 
the Command, Control, Communications, and Computers, Intelligence, Surveillance, and 
Reconnaissance (C4ISR) Architecture Framework Document. This document outlines, in 
exhausting detail, the required elements of any DoD architecture effort, regardless of the 
customer or architectural need. It promotes a common framework for all architectural efforts, 
describing required data elements, required views of the data, and suggested applications for the 
architecture once completed. 

The primary downfall of the DoD Architecture Framework is that it focuses on the 
views of the data, rather than the data itself. By mandating particular views, it forces the 
aspiring architect to focus on the architecture as a set of drawings and pictures, rather than focus 
on the relationships between the data elements, which is where the strength of the architecture 
lies. Because of the extent of the mandatory products, many organizations blindly go through 
the steps to meet the mandated requirements of the Framework document rather than take the 
time to understand what the architectures are and why they may be important to their 
organizations. This results in a ‘fill the check box’ approach to the architectures’ creation and 
ultimately results in architectures that are of little use to the creator or any of the other 
stakeholders in the domain. 

In this way, the document fails to recognize that different communities may wish to use 
the architectural data in different ways, thus taking away the power of a flexible, data-driven, 
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object-oriented approach. For instance, the requirements community is likely to take a much 
different approach to architecture than a system developer or user or maintained The focus of 
requirements is typically on the interactions of the many organizations and systems within their 
area of interest, also known as the ‘domain’ of their architecture. A system developer will 
likely focus on how his particular system interacts with other systems regardless of the domain; 
while a system maintainer may be interested in the evolution of a particular system over time. 
The current approach of the DoD Architecture Framework fails to capture these various needs 
of these separate communities, or ‘stakeholders.’ 

However, what the DoD Architecture Framework does, and does quite well, is 
establish a common vocabulary and structure for the creation of architectures in the DoD. This 
is an absolutely vital aspect of any significant architectural effort. In a sizable domain, especially 
one that consists of so many functional areas and distributed systems as the DoD, it is important 
to establish this common data model to facilitate integration of disparate architectural efforts. I 
will use much of the terminology of the framework document as a basis for the ontology of this 
thesis. 


1. Architecture Views 

So, to begin, the DoD Architecture Framework outlines 3 major categories of 
architectural products: Operational, System, and Technical. These categories have a strong 
foundation and are widely accepted and understood in the world of enterprise architecture 
development. These terms also are used as the foundational language of the proposed 
methodologies (Chapter IV) and are seen often throughout this thesis. 

a. Operational Architecture Views 

The framework describes the operational architecture view as “a description of 
the tasks, and activities, operational elements, and information flows required to accomplish or 
support a military operation.” In short, the operational architecture views equates to business 
modeling for the DoD. 
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Operational architecture views are generally independent of technology, 
systems, or organization/force structures. In theory, they should describe how missions and 
functional areas (i.e. Theater Air and Missile Defense, Close Air Support, or Anti-Submarine 
Warfare) are accomplished from an activity and information flow standpoint, regardless of what 
organizations or systems are available to accomplish the mission. However, in practice, 
because of the products mandated by the DoD Architecture Framework, these views are often 
modeled around existing force structures and systems, rather than considering how the 
mission/functional area should be accomplished regardless of a particular system or force 
implementation. 

This practice greatly reduces the reusability of the created architectures, as the 
information captured is often too specific to be applied to similar domains. Operational 
architectures ideally should be so generic that, for example, an architecture that captures the 
Close Air Support mission in one theater should be able to be re-used in another theater, as 
doctrinally the missions should be the same regardless of the units or systems which are 
implementing them. 

Within the DoD Architecture Framework, operational views are described 
using these basic architectural elements: nodes, activities, and information exchange 
requirements. Nodes are virtual entities that represent a collection of activities (and, within the 
Architecture Framework, systems, as well). Nodes are places where activity occurs. Example 
nodes might be: Command Post, Destroyer, or Fighter Wing. The operational views in the 
DoD Architecture Framework tend to be node-centric, i.e. they start with development of the 
nodes and describe activities and interactions at the node level. After the development of the 
nodes comes assignment of activities to the nodes. In most DoD architectures, activities are 
derived from the U nif ied Joint Task List (UJTL)—a living list of the common activities required 
to perform daily and wartime missions. Requirements for nodes to exchange information are 
documented Information Exchange Requirements (IER). Typically, IF Rs are defined as 
using an information element (the description of the information being exchanged) and two 
nodes. While it is preferable that IF Rs also list the activities within the nodes that generate the 
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need for the IER, it is often seen that activity modeling is not complete enough to meet this 
requirement. This focus of the operational view on the nodes and not the activities is another 
shortcoming of the DoD Architecture Framework. 

b. System Architecture Views 

The system view is “a description of systems and interconnections providing for, 
or supporting, warfighting functions.” In short, the system architecture views are wiring 
diagrams, showing systems and how they interconnect. 

Within the C4ISR Framework, architectural system views tend to take on the 
form of static representations of a given architectural domain. That is, they show specific 
instantiations of systems and how they are physically connected. This approach to systems 
architecture is, in this author’s opinion, one of the major shortcomings of the C4ISR 
Architecture Framework Document. This approach fails to capture the correct information to 
achieve system interoperability. 

These types of views, which show workstations and servers and circuits and 
routers are generally only of use at the micro-level—that is, they are useful to the personnel 
responsible for the maintenance of those systems locally, but generally not of much use to the 
actual engineering process for generating requirements and implementing them. Rather, system- 
to-system interoperability requires a macro view of the world. To achieve this, system 
architecture views must also take on a more generic approach of understanding how system 
types, as opposed to instantiations, are required to interoperate. For example, to someone 
responsible for documenting requirements for the Global Command and Control System 
(GCCS), it is less important to him to know that a GCCS system at Hickam Air Force Base 
(AFB) is located in Bldg A and connects to the SIPRNET via Router B, C, & D, as it is to 
know that GCCS needs SIPRNET connectivity to exchange information with the Theater Battle 
Management Core System (TBMCS.) This is one example of micro- versus macro-level 
system architectures. 
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Another shortcoming of the systems views in the DoD Architecture Framework 
is that it does not allow for the documentation of system capabilities versus requirements. While 
system requirements are an extremely important aspect of the acquisition and development 
processes, it does little good to the warfighter to know that two systems are required to 
exchange certain elements of information. Rather, it is more important in this case to understand 
whether the systems are capable of exchanging these information elements. This is an extremely 
important distinction, and a key shortcoming of the Architecture Framework that must be 
overcome. 

System views are typically defined using nodes , systems , and interfaces. The 
concept of nodes is equivalent to that in the operational view—a collection of systems capable 
of performing certain functions. Systems are defined at the level of the architect; however, 
system hierarchies are not easily supported, so it is up to the architect to maintain consistency 
and determine at what level ‘systems of systems’ are to be architected. Interfaces represent 
physical connections between systems. Usually, interfaces will only be represented if there is 
some meaning to the interface (i.e. information can actually be exchanged over the connection.) 
However, this points out another shortcoming of the Architecture Framework. That is, there 
are few dependencies between the operational and system views; and, therefore, they can be 
created independent of each other, with little to no coordination between the architects. 
Therefore, just because two systems have IF Rs in the operational view and interfaces in the 
systems view, this does not necessarily mean that those IF Rs are supported by the interfaces— 
the two systems may not be interoperable. This is another issue addressed by the methodology 
proposed in this thesis. 

c. Technical and “All” Architecture Views 

The technical architecture view is “the minimal set of mles governing the 
arrangement, interaction, and interdependence of system parts or elements, whose purpose is to 
ensure that a conformant system satisfies a specified set of requirements.” That is, the technical 
architecture is the standards on which the systems within the architecture are based. Often, as 
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in the case of the DoD, technical architectures are used to levy technology standards onto the 
systems that fall under its purview. Technical architectures focus on implementation decisions of 
standards across the enterprise domain. As this thesis focuses on the requirements definition 
process, it will not discuss technical architectures. 

The “All” architecture views are two additional products also mandated by the 
framework. They are primarily administrative in nature and serve to provide introductory and 
summary information of the architecture as well as provide an architectural dictionary of terms 
and acronyms. These views are useful in giving an overall description of the architecture and in 
attempting to gain data commonality; but disparate sets of dictionaries, which require no 
coordination between them, will never achieve the goal of an integrated data dictionary. This is 
another reason why a data-centric approach to architectures, using an object-oriented common 
architectural repository (database) is so necessary. 

2. C4ISR Core Architecture Data Model [9] 

The C4ISR Core Architecture Data Model (CADM) is the companion document to the 
C4ISR Architecture Framework. It describes the basic set of standardized entities that should 
be used when building C4ISR architectures. In short, the CADM describes every object, every 
attribute, every relationship contained within the C4ISR Architecture Framework. 

The CADM is designed to provide a common approach for organizing and portraying 
the structure of architecture information. By facilitating the exchange, integration, and 
comparison of architecture information throughout DoD, this common approach should help 
improve C4ISR architecture interoperability and reusability. 

It is in the interest of supportability and tractability of enterprise architectures that a 
common set of architectural data elements be developed—whether as part of the DoD 
mandate, or in any commercial architectural endeavor as well. This provides a basis for 
information sharing between architectures, with an end goal of someday being able to integrate 
existing architectures into a common database. It is important, for this reason that any DoD 
architecture efforts not deviate from the CADM. Appendix B shows the relationship between 
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the proposed architecture data model and the CADM, and demonstrates there are several 
shortcomings to the CADM that could be easily incorporated into the current model to achieve 
better data fidelity and facilitate a more dynamic incorporation of interoperability requirements 
and capabilities. 

B. JOINT OPERATIONAL ARCHITECTURE 

The Joint Operational Architecture (JOA) is the DoD’s premiere attempt at creating a 
common operational architecture. The JOA writers took a similar approach to the author in that 
they first defined their domain (all DoD) and functional areas (using Joint Vision 2010 goals). 
These concepts will be discussed further in Chapter IV. The JOA efforts are the best observed 
thus far in the DoD in attempts to create top-down operational architectures (requirements must 
come from the top); unfortunately, it will fall short of being useful for defining interoperability 
requirements due to lack of proper resourcing and support and because they have failed to take 
a data-driven approach to their architecture. Their static ‘picture’ approach is not dynamic 
enough to be of benefit to the acquisition community. The proposed methodology will address 
an alternative to these efforts. 

C. GLOBAL INFORMATION GRID (GIG) ARCHITECTURE 

The GIG Architecture effort, led by the Assistant Secretary of Defense for Command, 
Control, Communications, and Intelligence (ASD(C3I)) has quickly become the leading 
architectural effort in the Department of Defense. The GIG effort is currently attempting to do 
what few other architectural efforts have attempted in the past: it is attempting to create a 
domain-wide architecture by integrating existing architectural products. 

This undertaking is proving extremely difficult as the architects are finding that the 
existing architectural products suffer from the weaknesses of the DoD Architecture Framework 
discussed earlier (i.e. they lack common language, structure, data formats, etc.) However, the 
GIG Architecture effort has two strengths/advantages over other architectural efforts: 1) it is 
well resourced; 2) it has the ability to take a domain-wide approach to the architecture as it 
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comes from the highest levels of the Defense Department. This top-level view will prove 
extremely helpful in the creation of future architectures that will certainly be based on the efforts 
of the GIG architects. 

D. AP-233 

Application Protocol 233 (AP-233) is the more common name for ISO 10303-233, an 
emerging ISO systems engineering data exchange standard. It is relevant to this thesis work in 
that it also will attempt to allay system interoperability problems that are created when 
simultaneous development efforts are not coordinated. In the systems engineering community, 
there exist many tools designed to aid systems engineers in the capturing of requirements, 
capabilities, and physical implementations. In this sense, these tools are not unlike the many 
tools that exist to capture enterprise architectures. Over the years, these tools have been 
developed for specific projects at specific times with little thought or attention given to the idea 
that eventually, it might become important to exchange information between them. 

Now, the systems engineering community, namely through the International Council on 
Systems Engineering (INCOSE) and ISO, is attempting to bring interoperability to these tools 
through the creation of a common data standard. This work is comparative to the creation of 
the common architectural data repository proposed in this thesis and the two share many similar 
aspects, primarily in scope and purpose. 

AP-233 Working Draft 5 consists of several domains: requirements; functional design; 
physical design; graphical representation and layout; traceability management; configuration 
management; and industry process [13]. This design mirrors the intent of the proposed 
common architectural data repository (which will be discussed more in Chapters IV and V) 
especially in that it differentiates between requirements, capabilities (functional design), and 
implementation (physical design). But also in that it provides common standards for graphical 
representation (a key aspect of any architectural effort—including the proposed methodology), 
traceability and configuration management (the reasons for proposing a centralized data model) 
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and also in that it recognizes the many needs of its stakeholders through its ‘industry process’ 
domain. This domain focuses on risk management and other user-centric issues. 

AP-233 is still currently a draft standard and is in coordination. Recent publications 
indicate it may be published sometime in 2003. However, Appendix C contains that latest 
information on AP-233 and how the proposed architectural data model relates. 
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III. SOFTWARE & INTEROPERABILITY WITHIN THE DOD 


Software and interoperability are inextricably linked—especially in today’s world of high 
technology and software-driven communications systems. But the complexities behind what it 
means to be interoperable, how we define interoperability requirements, and how they get levied 
onto our software-intensive systems are not always appreciated. 

A. DEFINITION OF INTEROPERABILITY 

According to CJCSI 6121.01b, Interoperability and Supportability of National Security 
Systems, and Information Technology Systems, interoperability is defined as: (1) The ability 
of systems, units, or forces to provide services to and accept services from other systems, units, 
or forces and to use the services so exchanged to enable them to operate effectively together, 
and (2) The condition achieved among communications-electronics systems or items of 
communications-electronics equipment when information or services can be exchanged directly 
and satisfactorily between them or their users. In short, interoperability is achieved when every 
user has the ability to get the services or information they require in any situation and are able to 
use that information in the successful completion of their mission. 

This definition of interoperability is predicated upon the existence of an understanding of 
the requirements to be interoperable. In fact, CJCSI 6212.01b goes further on to state that for 
the purposes of this instruction, the degree of interoperability will be determined by the 
accomplishment of the proposed Inf ormation Exchange Requirements. In that sense, it would 
be impossible to understand to what extent units, systems, or users are interoperable without 
knowledge of their requirements to be so. This highlights the importance of a methodology to 
capture interoperability requirements and levy these requirements effectively on our systems. 

B. CURRENT INTEROPERABILITY SITUATION IN THE DOD 

Interoperability of DoD weapons and communications systems is among the top 
priorities of all our Unified CINCs. It is a problem that continues to grow, and our reliance on 
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information and information superiority in modem warfare will ensure its importance as we move 
deeper into the 21 st century. Concepts such as Joint Vision 2010 and Joint Vision 2020 
already rely heavily on the pre-existence of joint interoperable systems. These concerns are 
exacerbated as we consider a more global schema of federal and coalition (i.e. international) 
interoperability. 

But system interoperability is not just an exercise for the system or software developer. 
Many times, interoperability problems cannot be overcome by technology alone. According to 
Hamilton and Murtagh [3], “compatible systems, doctrine, and policy must exist”. And, a 
common, data-driven architectural approach is a flexible, maintainable methodology to bring 
these three very different, but very necessary and related aspects of the system development 
process together. Hamilton and Murtagh go further to state that requirements engineering is the 
first step towards achieving system interoperability. [3] 

C. HOW THE DOD DEFINES INTEROPERABILITY REQUIREMENTS 

CJCSI 3170.01b defines three primary documents it uses to capture requirements: the 
Mission Need Statement (MNS); Capstone Requirements Document (CRD); and Operational 
Requirements Document (ORD). Warfighter mission needs are defined in broad operational 
terms in a MNS document. Subsequently, the needs expressed in the MNS are developed into 
requirements in the forms of CRDs and ORDs. CRDs act to provide ORD development 
guidance for a mission area that forms a system of systems or family of systems. ORDs 
translate the MNS and CRD requirements into detailed, refined performance capabilities for a 
specific proposed system. [10] 

Currently, an interoperability requirement is captured as an element of the CRD and 
ORD architectures known as an Information Exchange Requirement (IER). JE Rs are defined as 
part of the Operational View of the architecture and are specifically captured in an architectural 
product known as the Operational Information Exchange Matrix. Figure 1 shows the data 
requirements of the Inf ormation Exchange Requirement, as depicted in the DoD Architecture 
Framework V2.0. 


16 



The Operational Information Exchange Matrix (OV-3), shown in Figure 1, is one of the 
many architectural products mandated by the DoD Architecture Framework. In fact, it is a 
mandatory part of all CRDs, ORDS, and C4I Support Plans (C4ISP). 1 These actions are a 
good first step towards capturing system and software interoperability requirements, but they 
have to date proven insufficient. 
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Figure 1. Operational Information Exchange Matrix (OV-3) - Representative Format 


D. MAJOR SHORTCOMINGS OF CURRENT DOD PROCES SES 

There are many shortcomings in both the DoD system acquisition process and the 
current handling of architectures that are preventing meaningful usage of the TF Rs identified to 
date. First, despite the mandatory architectural products, many systems are being fielded 
without CRDs, ORDs and C4ISPs. This indicates a lack of discipline in our system acquisition 
processes in that we continue to field systems that do not have validated requirements. 
Additionally, while the system developers are asked to create the C4ISPs, they are not 


1 C4ISPs contain all the information required to sustain a system (logistics plans, training 
plans, architectural plans) throughout its lifecycle. They are required at certain milestone 
decision steps for each DoD system, in accordance with the Government Information 
Systems Reform Act (GISRA) and the Clinger-Cohen Act (CCA). 
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responsible for creating the operational architecture products (requirements- driven) that are 
contained within them. These products are the responsibility of the requirements community. 

Second, the architectural information that is captured in these documents is located 
within the co nf ines of a paper document. There is no meaningful way to integrate this 
information with that contained within similar documents. These documents meet a periodic 
review cycle, but all too often they become ‘shelfware’ never to be referenced again after their 
initial creation. 

Third, there exists no central repository for the architectural information that does exist 
within the CRDs, ORDs, and C4ISPs; and, therefore, there exists no methodology for ensuring 
consistency between them. For instance, there is no formal method for ensuring that an TH R that 
the TBMCS ORD has documented with GCCS is, in turn, documented in the GCCS ORD in 
reverse. (In truth, there exists to date several IERs between TBMCS and GCCS that cannot 
be documented in reverse, as there exists no GCCS ORD) And, because these architectural 
products cannot be maintained as ‘living’ documents with dynamic updating of requirements and 
consistency between systems and functional areas, proper allocation of requirements to systems 
cannot be accomplished. 

Demonstrating these points, during a survey at HQ USPACOM conducted by a 
combined CINC Interoperability/ Joint Forces Program Office team on 1 March 2000, 
approximately sixteen documented or ongoing architecture efforts were revealed across the J2, 
J3, and J6. Each effort was separate and distinct. Each was separately funded and initiated. 

No centra li zed data repository existed even between these components of a single unified 
command headquarters. [6] And since that time, the number of these disparate architecture 
efforts has grown exponentially as architectures have become a mandatory part of the system 
acquisition process. 

E. SOFTWARE ENGINEERING AND INTEROPERABILITY 

Interoperability is accomplished by first identifying data needed by other users or 
systems, and then by arranging to share that data quickly enough that it is still useful upon receipt 
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by those other users or systems. [2] Data, data exchanges, interfaces and data-driven 
applications are all fall within the responsibility of the modem software engineer. Data formats 
and database design, system interfaces designs, application design and implementation—all of 
these activities fall into the realm of software engineering. 

Some might argue that many interoperability problems are hardware problems. But, 
diverse hardware-based communications systems require an overall software architecture in 
order to interoperate. [3] Added to this, modem communications systems (which bear the 
brunt of data requests and interchange problems) are software-intensive. Hardware is not easily 
changed, and fielded hardware systems often cannot be wholly replaced. Therefore, as a 
practical matter, interoperability is more easily achieved through software. [3] 

And, so, as today’s systems become more complex and more inter-related, and the 
requirements for seamless inf ormation flows and transfers grow faster than the technology, it is 
clear that software engineers (and all system engineers) need a better architecture-based system 
to capture and define interoperability requirements. 
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IV. ENTERPRISE ARCHITECTURE FOR SOFTWARE INTEROPERABILITY 


An object-oriented approach to enterprise architectures may be the solution that can 
bring system developers, requirements experts, policy, and doctrine together to form a dynamic 
approach to the systems and software requirements engineering processes and allow these all- 
too-disparate communities to find a common ground for communication. 

A. DEFINITION OF ENTERPRISE ARCHITECTURE 

In its most basic form, an architecture is simply a description of objects and the 
relationships between these objects. Any system, software, enterprise, or other architecture can 
be described so. 

Enterprise architecture provides a top-level model of how information flows across the 
organizations within the enterprise domain. It ident if ies the key nodes, potential constraints, and 
the relationships between these nodes. It is a cornerstone to integrating or updating 
technologies and understanding what data is needed where and when. [6] In short, enterprise 
architecture equates to a business modeling method. 

As with many methods, enterprise architectures can be used to demonstrate different 
ideas and concepts depending on who is using them, and how they are used. On one side, they 
can be used to describe business processes, information flows, and activities. In this sense, 
enterprise architecture provides the underlying framework, which defines and describes the 
platform required by the enterprise to attain its objectives and achieve its vision. [4] In this way, 
enterprise architectures can be used to capture a common perspective--a common vision--of 
how a business domain should function. The objects of the architecture may be activities, 
grouped together into roles or functions, with required information flows representing the 
relationships between the objects. 

From another angle, enterprise architectures can be used to describe information 
technology (IT) capabilities, their networks, and their functions. In this case, the architecture 
provides a networking diagram, which defines the capabilities the enterprise has to achieve its 


21 



objectives and vision. In this way, enterprise architectures can be used to capture existing 
capabilities and future needs in any networking domain. The objects of this architecture may be 
systems, their subcomponents, and the transactions that are required and/or supported between 
these components. 

B. BENEFITS OF ENTERPRISE ARCHITECTURE 

Enterprise architectures provide a framework for modeling of business practices and 
allocating systems to that framework. The techniques are extremely flexible and can be 
designed to benefit a number of different communities, even within the same business domain. 
For instance, enterprise architecture techniques can be used to capture warfighting doctrine 
from the planning and requirements communities just as easily as it can be used to demonstrate 
system-to-system interactions. And, it is just as easily adaptable to software integration 
(relationship between software components and modules) as it is to system interoperability. 

This is realized through recognition that the architecture is not a collection of paper drawings, 
but is rather a structured database, by which the data elements can be related and viewed in any 
number of ways, depending on the interests of each particular user (or sets of users). 

When combined with the use of an object-oriented, relational architecture database that 
can be easily updated, maintained, and reused, there are many benefits that can be rea li zed over 
the current processes. First, repeated duplication of efforts and multiple data requests would be 
reduced. Instead of multiple architectural efforts which are geared towards a specific customer, 
by incorporating a data-centric, central repository approach, all architectural efforts eventually 
contribute to the corporate knowledge of the entire community. And, by embedding the data 
and the use of that data into the business processes of the organization, the demand for (static) 
products is reduced, if not eliminated. [6] Furthermore, enterprise architecture planning 
considers both the strategic and tactical need for information exchange in supporting the 
organization’s mission. Using a data-centric approach, time attributes would provide the 
necessary information to improve contingency and resource planning and allocations. [5] 
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C. NEW ARCHITECTURAL MODEL 

The proposed architectural model uses an enterprise architecture approach to define, 
capture, levy, and maintain system interoperability requirements. It is a data-centric, object- 
oriented architectural model that focuses on the relationships between architectural elements, not 
picture representations. Furthermore, it simplifies the current DoD models to capture only those 
pieces of information required for achieving interoperability. 

The model is designed to recognize the distinct needs of all a system’s stakeholders, 
allowing for different architectural foci, constructed from the same underlying data. It is also 
tailored to meet the ultimate goal of interoperable systems and forced, structured coordination 
between the planning/rcquircmcnts and acquisition communities. 

Finally, the model spans time, allowing the various communities to incorporate the 
concepts of time-phased requirements and spiral development. 

D. ELEMENTS OF PROPOSED ARCHITECTURAL MODEL 

1. Step One: Establish the Domain and All Its Stakeholders 

In order to create a valid architecture, it is vital to have a clear understanding of the 
environment that the architecture is intended to model and the questions/issues the architecture is 
intended to answer. Example domains could be: a hospital; Air Force Command and Control; 
a collection of integrated software components, like the Common Operating Environment, or 
Microsoft Office; Theater Air and Missile Defense; the entire Department of Defense; a single 
software application; or, all Federal Government Agencies. Domains can be very large or very 
small, depending on the interest of the architect. There is no right or wrong answer or 
approach, as long as the intentions are clear from the beginning and consistency is maintained 
throughout. The domain also creates lim its and brings discipline to the architectural process. 

The desired result of this step is a definition of the domain of the architecture and a fist 
of all the stakeholders and their responsibilities with respect to the environment being modeled. 
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For this thesis, I have chosen to storyboard the domain of home security. Within 
that domain the following groups own some kin d of stake in the systems of that domain: 


Stakeholder 

Responsibilities 

Homeowner 

Generates requirements based on his security desires 

Monitoring Service 

Provides service based on homeowner demands 

Emergency 

Response Services 

Responds as needed, maintains public systems 

System Developers 

Responsible for engineering system components 

System Installers 

Responsible for installing system components 

System Maintainers 

Responsible for maintaining system components 


Table 1. Architectural Domain Stakeholders 


a. Users 

The homeowner, monitoring service and emergency response services each 
represent potential users of the developed system, and, thus, ultimately will drive the 
requirements of the domain. In large commercial domains, such as this, it is nearly impossible to 
reach a consensus of requirements between these disparate groups. Additionally, even with 
consensus, it may not be feasible for the developer to include all users’ requirements in a single 
release. In the Defense domain, where the user base is much smaller and more easily accessible 
than usually found in commercial industry, and the systems and applications more tailored to 
specific functions within the domain, it is much more likely to see a user directly involved in the 
requirements generation aspect of a system—in fact, it is a basic tenet of Defense System 
Acquisition. But, even in this semi-controlled environment, management of ever-changing 
priorities and disparate user communities tracking and monitoring of requirements is an 
enterprise-wide challenge. 

In the architectural process, it is the users’/requirements community’s 
responsibility to capture the requirements of their domain as elements of the architecture. The 
proposed architectural model aids the requirements community by allowing them to capture their 
domain requirements (activities, information exchanges, etc.) in a central architectural repository, 
which can then be shared with other communities of interest. Information exchange 
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requirements, which by definition occur between two or more activities, are automatically 
assigned to the appropriate each activity (a required data element) eliminating the mismatches 
between multiple paper requirements documents. Combined with a common data dictionary, 
this approach also will prevent confusion and miscommunication between disparate 
requirements and user communities. 

b. Developers 

System developers are responsible for implementing requirements, as defined 
by the users or designated requirements community, into capabilities. In today’s defense and 
commercial environments, it is often the case that the requirements of a domain will be met by 
multiple systems (and, thus, system developers) and that often a single system will meet partial 
requirements of many domains. Therefore, the system developer needs to understand how his 
system fits into the integration of multiple systems within a single domain, and how it fits into the 
integration across multiple domains. 

With respect to the architecture, it is the responsibility of the system developer 
to track the requirements that have been levied on his system and their implementation. He 
reads the requirements data, as defined by the user community, and submits to the central 
architecture repository his plans to implement these requirements as capabilities. In this way, 
users and other interested communities can track when capabilities (including interoperabilities 
between multiple systems) will be available to them. 

c. System Installers and Maintainers 

A centralized system architecture is even of use to the individual system 
installers and maintainers, as it provides them cohesive insight into the current system 
interactions and how those may change in the future. System installers and maintainers gain 
insight from the architecture through a documented understanding of how the system is intended 
to be employed and the other systems with which it is supposed to interact. Future and planned 
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capabilities and requirements identify potential needs for installation and maintenance training 
impacts. 

2. Step Two: Understand Your Business 

Within each domain, there may be several functional areas or mission areas that must be 
further defined. These functional areas can be architected independently, but will normally be 
linked via common requirements and common system implementations. Within each functional 
area, it is necessary to accomplish the following: 

- List/define all the activities required to execute the processes within the functional area 
(hierarchically group activities, if required) 

- Determine the necessary information exchanges between those activities 

- Smartly aggregate activities into roles/nodes 

The desired result of these steps is a complete activity model for each functional area 
within the domain, grouped into actors/roles/nodes, with information exchanges identified 
between these groupings. 

a. Define Functional Areas 

The identification of functional areas within the architectural domain is an 
optional step, but particularly useful for any larger scale architectural efforts. Functional areas 
provide a decomposition of the domain into smaller-scale and, thus, more manageable 
architectural projects, allowing for better organization of and control over the architectural 
process, as a whole. 

If one was architecting the Department of Defense, example functional areas 
could be Theater Air and Missile Defense, Command and Control, or Close Air Support. If 
one was architecting a Microsoft Office competitor, example functional areas could be word 
processing, graphics, spreadsheet design, or messaging. 

It does not matter how the architectural effort is decomposed, as long as the 
breakout is applied consistently throughout the architecture. The identification of the number 
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and scope of the functional areas belongs in the realm of the requirements community, but 
should be agreed to by all stakeholders. For smaller-scale efforts, the decomposition may not 
be necessary, if proper configuration management of the architectural elements can be 
maintained using a more global construct. However, all the activity modeling still applies. 


In the continuing example of Home Security, I have chosen to architect the 
following three functional areas: Intruder Detection & Response; Fire Detection & Response; 
and Flood Detection & Response. 


Functional Area 

Description 

Intruder Detection & 

Response 

Home/Business Security. To monitor and detect 
unauthorized entry into the secured area and sound 
alarms/alert authorities, as necessary. 

Fire Detection & Response 

General Security. To detect smoke and/or fire 
within the monitored area and sound alarms/alert 
authorities, as necessary. 

Flood Detection & Response 

Home/Business Security. To detect flood 
conditions (i.e. excess water levels) within the 
monitored area and alert authorities, as necessary. 


Table 2. Functional Area Descriptions 


b. Define Activities Required to Execute the Functional Area 

The identification of the activities required to execute each functional area is the 
most critical aspect of the architecture development. It is the area that will require the most 
research and most thorough understanding of the domain. It is also the most likely area of 
contention and need for group consensus, and often the most time-consuming. The activities 
will serve eventually as the fundamental basis for all other architectural products, and, therefore, 
must be carefully considered and constantly reviewed to ensure they accurately portray the 
functional area and the architect’s desired product. 

As with other architectural elements, there is no right or wrong way to define an 
activity, as long as the standard is applied consistently to the entire architecture. These activities 
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eventually will serve as endpoints for interoperability requirements and as the basis for system 
requirements and capabilities. Their use towards these ends must also be considered in the 
architecture’s development to ensure the right level of detail is captured in the activity model. 

Risks include creating an activity model that is too high-level and cannot support 
requirements definition, as there is not enough detail to assign the requirements to any one 
particular node or system. Furthermore, too much detail can slow the architecture process and 
create a scalability factor that makes the rest of the effort intractable. These risks can be 
reduced by taking a hierarchical approach to the activity modeling which allows for the data to 
be viewed at whichever level of detail is appropriate to the user. For instance, if architecting the 
functional area of Global Command and Control, one might look at high-level activities such as 
Deployment Planning, Situational Awareness, and Intelligence Gathering and the interactions 
between these activities. But, one may want to dive deeper to find out that within deployment 
planning are subactivities, such as personnel deployment processing, equipment transport, and 
in-theater resupply. The Universal Joint Task List (UJTL), the DoD’s listing of all warfighting 
tasks, is an excellent example of an existing, hierarchically grouped activity model. 


In the area of Home Security, the following activities were identified for each of 
the functional areas: 


Intruder Detection 

Fire Detection 

Flood Detection 

Detect Door Opening 

Detect Smoke 

Detect Flood 

Detect Window Opening 

Detect Heat 

Notify Monitoring Service 

Activate Alarm 

Activate Alarm 

Notify Homeowner 

Notify Monitoring Service 

Notify Monitoring Service 


Notify Homeowner 

Notify Fire Department 


Notify Police 

Notify Homeowner 


Arm System 

Respond to Fire/Alarm 


Disarm System 



Investigate/Respond to Alarm 




Table 3. Initial Activity List 
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Each functional area should not draw from a separate and distinct list of 
activities, however. For instance, it is not necessary for each functional area to contain the 
activity “Notify Homeowner.” When the initial activity list is created, it is necessary to design it 
in such a way as to promote sharing across the functional areas. Creating an activity tree that is 
easily navigable by all parties is one way to promote this kind of cooperation. In the following 
tables, I demonstrate one method for creating such a hierarchy. 

Starting with the Intruder Detection & Response area, the listed activities are 


grouped into similar categories. 


Intruder Detection Activities 


Detect Door Opening - ' 


Detect Window Opening -— 


Activate Alarm \ 


Notify Monitoring Service — 


Notify Homeowner 


Notify Police ' 


Arm System ^ 


Disarm System 


Investigate/Respond to Alarm - 



A1. Maintain Physical Security 


A1 -1. Detect Door Opening 


A1 - 2. Detect Window Opening 


A2. Make External Notifications 


A2-1. Contact Monitoring Service 


A2-2. Contact Homeowner 


A2 - 3. Contact Police 


A3. Activate Alarm 


A4. System Operation 


A4-1. Arm System 


A4-2. Disarm System 


A5. Emergency Response 


1 A5-1. Investigate/Respond to Security Alarm 


Figure 2. Intruder Detection Activity Groupings 


As this is a new architecture effort, this list forms the basis for a universal activity 
list. Other activities to be defined for other functional areas will build off this list such that 
common activities need not be defined twice. If this were a modification or addition to an 
existing architecture, it would be important during the activity definition phase to ensure that no 
duplicate activities were being added to the system. This requires research and discipline on the 
part of the architect in understanding the existing architectural elements. 
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Continuing this task through the other functional areas, the following list of 


activities is created: 


A1. Maintain Physical Security 
A1 -1. Detect Door Opening 
A1 - 2. Detect Window Opening 
Al-3. Detect Smoke 
Al-4. Detect Heat 
A1 - 5. Detect Flood 
A2. Make External Notifications 
A2-1. Contact Monitoring Service 
A2-2. Contact Homeowner 
A2 - 3. Contact Police 
A2-4. Contact Fire Department 
A3. Activate Alarm 
A4. System Operation 
A4-1. Ann System 
A4-2. Disarm System 
A5. Emergency Response 

A5 -1. Investigate/Respond to Security Alarm 
A5 - 2. Re spond to Fire Alarm 

Table 4. Combined Activity List 


After the initial round of activity modeling is complete, it is important to vet the 
requirements through as many appropriate stakeholders as possible. One set of activities that 
will likely to have been missed—and are of utmost importance to the developer, and thus, the 
software engineer—is the set of derived activities. Derived activities are those that may not be 
implicitly required but become necessary to fully exercise the domain. One example of a 
derived activity is a decision point. For instance, in the above case, while the security system 
may want to automatically notify the monitoring service in the case of any anomaly, there may be 
some user intervention required to make a decision as to whether the situation warrants 
homeowner or emergency services to respond. It is important to capture this decision-making 
activity as it is not only part of the use-case for the functional area, but because it will generate 
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information exchange requirements itself. The decision was made to group these decision points 
separately from the notification activities, and, therefore, the final list of activities follows. 


Al. Maintain Physical Security 
A1 -1. Detect Door Opening 
Al - 2. Detect Window Opening 
Al-3. Detect Smoke 
Al-4. Detect Heat 
Al - 5. Detect Flood 
A2. Make External Notifications 
A2-1. Contact Monitoring Service 
A2-2. Contact Homeowner 
A2 - 3. Contact Police 
A2-4. Contact Fire Department 
A3. Activate Alarm 
A4. System Operation 
A4-1. Ann System 
A4-2. Disarm System 
A5. Situation Analysis/Decision Point 

A5-1. Decide if Homeowner Intervention is Required 
A5-2. Decide if Emergency Response is Required 
A6. Emergency Response 

A6-1. Investigate/Respond to Security Alarm 
A6-2. Respond to Fire Alarm 

Table 5. Final Activity List 

c. Define Information Exchange Requirements Between Activities 

Once an activity list is in relatively final form 2 the next step to the architecture’s 
development is to define the information exchange requirements between those activities. This 
task should be completed without consideration of current system capabilities or organizational 
structure. These will be considered in a later step. Rather, this should be constmcted in an 
idealistic manner of how things should work, as opposed to how they do. In the DoD, joint 


2 Architectures are, by definition, living documents. However, in the initial development phase it is useful to 
benchmark certain elements in order to create a baseline of architectural elements from which to grow. This 
is especially important with respect to the activities, as they form the foundation for the rest of the 
architecture’s development. While modifications to the activity list are possible, it is not recommended until 
the architecture is more mature (i.e. the first round of inputs is completed for the rest of the elements.) 
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doctrine is the key to determining interoperability requirements. Doctrine tells us how to fight 
and how we fight determines interoperability requirements. Policy sets the bounds on 
acceptable doctrine. [3] 

In defining IERs, it is important to document not only the activities (endpoints of 
the IER,) but also the Inf ormation Element that is to be exchanged. In cases where the same set 
of activities is exchanging multiple pieces of information, this should be considered as multiple 
IERs; and, likewise, in cases where one Information Element is being exchanged between 
multiple sets of activities, this, too, should be considered as multiple IERs. However, in cases 
where the same activities are exchanging the same Information Element in different functional 
areas of the same architecture, this need not be captured twice, as the IE R list will be available 
to all architects within the domain, just as the activity list. 

Use cases are particularly useful in the identification of IE Rs, and it is the 
author’s methodology of choice. The key is to mn through all the possible scenarios in 
generating the IE R list. But, regardless of the methods, the result of this task is a listing of all the 
IE Rs applicable to the architectural domain. 

Continuing the example of home security, a typical intruder scenario was 
developed to identify the necessary IERs. 

1) A door or window opening is detected. 

2) The alarm is sounded and the monitoring service notified. 

3) The monitoring service decides whether to notify the homeowner directly. 

4a) If 3) is no, the alarm is reset and scenario stops. 

4b) If 3) is yes, the homeowner is notified. 

5) The monitoring service (with or without the input of the homeowner) decides 
of the authorities need to be contacted. 

6a) If 5) is no, the alarm is reset and the scenario stops. 

6b) If 5) is yes, the authorities are contacted. 

7) The authorities respond to the alarm. 
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Based on this scenario, the following list of lE Rs was generated: 



Originating Activity 

Receiving Activity 

Information Element 

1 

Al -1. Detect Door Opening 

A2-1. Contact Monitoring Service 

Door Status 

2 

Al -1. Detect Door Opening 

A3. Activate Alarm 

Door Status 

3 

A1 - 2. Detect Window Opening 

A2-1. Contact Monitoring Service 

Window Status 

m 

Al-2. Detect Window Opening 

A3. Activate Alarm 

Window Status 

5 

A2-1. Contact Monitoring 

Service 

A5-1. Homeowner Intervention 

Decision 

Alarm Notification 

6 

A5-1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Intervention Decision 

7 

A5-1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Alarm Notification 

8 

A2-2. Contact Homeowner 

A5-2. Emergency Intervention 
Decision 

Alarm Notification 

9 

A5-2. Emergency Intervention 
Decision 

A2-3. Contact Authorities 

Intervention Decision 

10 

A5-2. Emergency Intervention 
Decision 

A2-3. Contact Authorities 

Alarm Notification 

11 

A2-3. Contact Authorities 

A6. Emergency Response 

Alarm Notification 


Table 6. Intruder Detection IER List 

Following in a similar fashion for the fire detection and flood detection functional 


areas, the following IER Lists were generated: 



Originating Activity 

Receiving Activity 

Information Element 

1 

Al-3. Detect Smoke 

A2-1. Contact Monitoring Service 

Alarm Notification 

2 

Al-3. Detect Smoke 

A2-3. Contact Authorities 

Alarm Notification 

3 

Al-3. Detect Smoke 

A3. Activate Alarm 

Smoke Detection 

m 

Al-2. Detect Heat 

A2-1. Contact Monitoring Service 

Alarm Notification 

5 

Al-2. Detect Heat 

A2-3. Contact Authorities 

Alarm Notification 

6 

Al-2. Detect Heat 

A3. Activate Alarm 

Heat Detection 

7 

A2-1. Contact Monitoring 

Service 

A5-1. Homeowner Intervention 

Decision 

Alarm Notification 

8 

A5-1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Intervention Decision 

9 

A5 -1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Alarm Notification 

10 

A2-3. Contact Authorities 

A6. Emergency Response 

Alarm Notification 


Table 7. Fire Detection IER List 
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Originating Activity 

Receiving Activity 

Information Element 

1 

A1 - 5. Detect Flood 

A2-1. Contact Monitoring Service 

Flood Notification 

2 

A2-1. Contact Monitoring 

Service 

A5-1. Homeowner Intervention 

Decision 

Alarm Notification 

3 

A5-1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Intervention Decision 

■ 

A5 -1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Alarm Notification 

5 

A2-2. Contact Homeowner 

A6. Emergency Response 

Alarm Notification 


Table 8. Flood Detection IER List 


Just as with the activity lists, if these functional areas are architected 
independently, it may be necessary to evaluate the IF Rs together to el im inate duplicity. The 
table below shows the aggregate IER List: 



Originating Activity 

Receiving Activity 

Information Element 

1 

Al -1. Detect Door Opening 

A2-1. Contact Monitoring Service 

Door Status 

2 

Al -1. Detect Door Opening 

A3. Activate Alarm 

Door Status 

3 

Al-2. Detect Window Opening 

A2-1. Contact Monitoring Service 

Window Status 

m 

Al-2. Detect Window Opening 

A3. Activate Alarm 

Window Status 

5 

A2-1. Contact Monitoring 

Service 

A5 -1. Homeowner Intervention 

Decision 

Alarm Notification 

6 

A5-1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Intervention Decision 

7 

A5 -1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Alarm Notification 

8 

A2-2. Contact Homeowner 

A5-2. Emergency Intervention 
Decision 

Alarm Notification 

9 

A5-2. Emergency Intervention 
Decision 

A2-3. Contact Authorities 

Intervention Decision 

10 

A5-2. Emergency Intervention 
Decision 

A2-3. Contact Authorities 

Alarm Notification 

11 

A2-3. Contact Authorities 

A6. Emergency Response 

Alarm Notification 

12 

Al-3. Detect Smoke 

A2-1. Contact Monitoring Service 

Alarm Notification 

13 

Al-3. Detect Smoke 

A2-3. Contact Authorities 

Alarm Notification 

14 

Al-3. Detect Smoke 

A3. Activate Alarm 

Smoke Detection 

15 

Al-2. Detect Heat 

A2-1. Contact Monitoring Service 

Alarm Notification 
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16 

Al-2. Detect Heat 

A2-3. Contact Authorities 

Alarm Notification 

17 

Al-2. Detect Heat 

A3. Activate Alarm 

Heat Detection 

18 

A2-1. Contact Monitoring 

Service 

A5 -1. Homeowner Intervention 

Decision 

Alarm Notification 

19 

A5-1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Intervention Decision 

20 

A5 -1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Alarm Notification 

21 

A2-3. Contact Authorities 

A6. Emergency Response 

Alarm Notification 

22 

Al-5. Detect Flood 

A2-1. Contact Monitoring Service 

Flood Notification 

23 

A2-1. Contact Monitoring 

Service 

A5 -1. Homeowner Intervention 

Decision 

Alarm Notification 

24 

A5-1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Intervention Decision 

25 

A5 -1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Alarm Notification 

26 

A2-2. Contact Homeowner 

A6. Emergency Response 

Alarm Notification 


Table 9. Aggregate IER List 



Originating Activity 

Receiving Activity 

Information Element 

1 

Al -1. Detect Door Opening 

A2-1. Contact Monitoring Service 

Door Status 

2 

Al -1. Detect Door Opening 

A3. Activate Alarm 

Door Status 

3 

Al-2. Detect Window Opening 

A2-1. Contact Monitoring Service 

Window Status 

m 

Al-2. Detect Window Opening 

A3. Activate Alarm 

Window Status 

5 

A2-1. Contact Monitoring 

Service 

A5-1. Homeowner Intervention 

Decision 

Alarm Notification 

6 

A5-1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Intervention Decision 

7 

A5 -1. Homeowner Intervention 

Decision 

A2-2. Contact Homeowner 

Alarm Notification 

8 

A2-2. Contact Homeowner 

A5-2. Emergency Intervention 
Decision 

Alarm Notification 

9 

A5-2. Emergency Intervention 
Decision 

A2-3. Contact Authorities 

Intervention Decision 

10 

A5-2. Emergency Intervention 
Decision 

A2-3. Contact Authorities 

Alarm Notification 

11 

A2-3. Contact Authorities 

A6. Emergency Response 

Alarm Notification 

12 

Al-3. Detect Smoke 

A2-1. Contact Monitoring Service 

Alarm Notification 

13 

Al-3. Detect Smoke 

A2-3. Contact Authorities 

Alarm Notification 
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14 

Al-3. Detect Smoke 

A3. Activate Alarm 

Smoke Detection 

15 

Al-2. Detect Heat 

A2-1. Contact Monitoring Service 

Alarm Notification 

16 

Al-2. Detect Heat 

A2-3. Contact Authorities 

Alarm Notification 

17 

Al-2. Detect Heat 

A3. Activate Alarm 

Heat Detection 

18 

Al-5. Detect Flood 

A2-1. Contact Monitoring Service 

Flood Notification 


Table 10. Final IER List 


By examining the IF Rs from all the functional areas together, we can see that 5, 
18, and 23; 26, 11, and 21; 6, 19, and 24; and 7, 20, and 25 are duplicative. Therefore, 8 
redundant IF Rs can be e lim inated resulting in the final list of IF Rs applicable to the domain, 
found in Table 10: 

d. Smartly Aggregate Activities Into Roles/Nodes 

At this point, all the activities and information exchange requirements between 
those activities have been identified. Now, it is necessary to group these activities into roles (or 
nodes) based on the needs of the functional area. 

There are many different considerations to take into account when making these 
groupings. First, you may want to cluster activities together that would normally be 
accomplished by the same group, i.e. those activities that make sense to be together. Second, 
you may want to cluster activities to e lim inate the need for information exchanges, i.e. making 
these exchanges intra-nodal instead of inter-nodal. This approach could reduce risk introduced 
by system interoperability problems. If redundancy is important in the functional area (as it is in 
many DoD functional areas,) it may make sense to assign activities to multiple roles. There 
exists no right or wrong combination of these approaches--so long as by the end of the step, the 
players/roles within the functional area have been defined and there is a clear assignment of 
activities (requirements) and information exchange requirements between them. 

Continuing with the home security example, the activities within the different 
functional areas were aggregated as depicted in the following figures: 
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Al. 


A2. 


Maintain Physical Security 
A1 -1. Detect Door Opening 
Al-2. Detect Window Opening 
Make External Notifications 



Door Sensor 


A2-1. Contact Monitoring Service 
A2-2. Contact Homeowner 
A2-3. Contact Authorities 
A3. Activate Alarm 
A4. System Operation 
A4-1. Arm System 
A4-2. Disarm System 
A5. Situation Analysis 

A5-1. Homeowner Intervention? 
A5-2. Emergency Intervention? 
A6. Emergency Response 



Figure 3. Intruder Detection Roles 


Al. 

Al-5. 

A2. 

A2-1. 

A2-2. 

A5. 

A5-1. 

A6. 


Maintain Physical Security 
Detect Flood 
Make External Notifications 
Contact Monitoring Service 
Contact Homeowner 
Situation Analysis 
Homeowner Intervention? 
Emergency Response 



Figure 4. Fire Detection Roles 


Al. 
Al-3. 
Al-4. 
A2. 
A2-1. 
A2-2. 
A2-3. 
A3. 
A5. 
A5- 
A6. 


1 . 



Maintain Physical Security 
Detect Smoke 
Detect Heat 
Make External Notifications 
Contact Monitoring Service 
Contact Homeowner 
Contact Authorities 
Activate Alarm 
Situation Analysis 
Homeowner Intervention? 
Emergency Response 


Figure 5. Flood Detection Roles 
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Once a role is defined and activities assigned to it, the role inherits the 
Inf ormation Exchange Requirements of those activities. It is in this manner that a role is given 
responsibility for a particular TE R. In the post-assignment analysis, it may be found that several 
of these TE Rs will disappear from the top-level operational architecture, as both the originating 
and receiving activities are contained within the same node. By looking at the example of home 
security, the following “aggregated” TE R list (by functional area) was created through such an 
analysis: 


■ 

Originating 

Role 

Originating Activity 

Receiving 

Role 

Receiving Activity 

Information 

Element 

ID 1 

Door Sensor 

Al-1. Detect Door 
Opening 

System 

Controller 

A3. Activate 

Alarm 

Door Status 

ID2 

Window 

Sensor 

Al-2. Detect Window 
Opening 

System 

Controller 

A3. Activate 

Alarm 

Window 

Status 

ID3 

System 

Controller 

A2-1. Contact 

Monitoring Service 

Monitoring 

Service 

A5-1. 

Homeowner 

Intervention 

Decision 

Alarm 

Notification 

ID4 

Monitoring 

Service 

A2-2. Contact 

Homeowner 

Homeowner 

A5-2. Emergency 
Intervention 

Decision 

Alarm 

Notification 

ID5 

Homeowner 

A5-2. Emergency 
Intervention Decision 

Monitoring 

Service 

A2-3. Contact 

Authorities 

Intervention 

Decision 

ID6 

Monitoring 

Service 

A2-3. Contact 

Authorities 

Emergency 

Response 

Agency 

A6. Emergency 
Response 

Alarm 

Notification 


Table 11. Intruder Detection Aggregated IER List 



Originating 

Role 

Originating Activity 

Receiving 

Role 

Receiving Activity 

Information 

Element 

EDI 

Smoke 

Detector 

Al-3. Detect Smoke 

System 

Controller 

A3. Activate 

Alarm 

Smoke 

Detection 

FD2 

Heat 

Detector 

Al-2. Detect Heat 

System 

Controller 

A3. Activate 

Alarm 

Heat Detection 
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FD3 

System 

Controller 

A2-1. Contact 

Monitoring Service 

Monitoring 

Service 

A5-1. 

Homeowner 

Intervention 

Decision 

Alarm 

Notification 

FD4 

Monitoring 

Service 

A2-2. Contact 

Homeowner 

Homeowner 

A6. Emergency 
Response 

Alarm 

Notification 

FD5 

System 

Controller 

A2-3. Contact 

Authorities 

Emergency 

Response 

Agency 

A6. Emergency 
Response 

Alarm 

Notification 


Table 12. Fire Detection Aggregated IER List 



Originating 

Role 

Originating Activity 

Receiving 

Role 

Receiving Activity 

Information 

Element 

ELI 

Flood 

Sensor 

A1 - 5. Detect Flood 

System 

Controller 

A2-1. Contact 
Monitoring Service 

Flood 

Notification 

FL2 

System 

Controller 

A2-1. Contact 

Monitoring Service 

Monitoring 

Service 

A5-1. 

Homeowner 

Intervention 

Decision 

Alarm 

Notification 

FL3 

Monitoring 

Service 

A2-2. Contact 

Homeowner 

Homeowner 

A6. Emergency 
Response 

Alarm 

Notification 


Table 13. Flood Detection Aggregated IER List 


Through this exercise, we see that the list of 18 previous lE Rs within the domain 
has been reduced to 14, thus simplifying the intemodal dependencies for the functional area. 
Depending on how systems are implemented within the domain, these 4 IR Rs may yet still be 
system interoperability requirements (some nodes may be made up of multiple systems,) but this 
aspect of the architecture will be accounted for in later steps. 

This particular activity (of defining nodes) gains particular strength when using a 
data-centric approach to the architecture. In his design of a functional area, the architect may 
choose only certain activities for certain roles. But because all the activities within his functional 
area (and the entire domain, for that matter) are visible to the architect at any time, it is relatively 
easy to expand a role if it becomes necessary later in the architecture’s development. 
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e. Role-Centric Architecture - Operational Perspective 


The tasks embedded in Step Two focused on the creation of activities, 
information exchange requirements and roles. Put together, these objects and the defined 
relationships between them are the foundation for the Operational Perspective of the Role¬ 
centric Architecture. Role-centric architectures are intended to be of greatest to use to the 
planning community. Requirements developers, users, any stakeholder who has direct impact 
on the operational requirements of a system gains the most benefit from the information the role- 
centric architectures contain. To complete the operational portion of the role-centric 
architecture, activities were defined and hierarchically organized (parent-child activities defined), 
Information Exchange Requirements were identified as need-lines between activities, and 
Roles were defined as groupings of these activities. The beginning of the proposed architectural 
data model, capturing these relationships, is included in Figure 6. 



Figure 6. Operational Perspective, Role-Centric Architecture Data Model 3 


3 Although objects in the model contain attributes, these are provided as an example of the types of 
attributes that may want to be considered. These may change depending on the focus of the architecture 
and should not be considered as the only attributes that may be assigned these elements. 
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To this point, the interoperability requirements for the domain are defined and 
have been assigned (along with their parent activities) to nodes within the domain. Now it is a 
matter of assigning these activities and IF Rs to systems while providing a framework for growth 
and maintenance. 


3. Step Three: Document Your Capabilities 

In order to assign activities to systems, it is necessary to first understand the current 
capabilities of the systems that are available to a given functional area. This involves first 
documenting current system capabilities in the same terms in which operational activities were 
defined. After that step is complete, system interfaces are defined in the same terms in which 
information exchange requirements were defined. 

Like activities, the architecture supports the concept of embedded systems. A system 
may be stand-alone, or may be part of a system of systems or family of systems. In this way, 
the architecture also supports viewing systems at a micro-level. A single software application 
can be broken into its separate modules to show which of those modules perform which 
activities and where within the application the interface to the external system lies. In this way, 
the architecture can be used to capture threads and traces within a system. 

Additionally, this feature is useful to system integrators who are responsible for fielding a 
system of integrated components—often seen in the DoD, and often with the integrator having 
little to no time during software code and development. For instance, the Global Command and 
Control System is comprised of several software applications, like JOPES, COP, GSORTS, 
TRANSCOP, and 13, just to name a few. This methodology, if applied to its fullest, can be 
used to show not only how GCCS interacts with it external systems, but how the components of 
GCCS interact with each other to complete the requirements of the functional area. Instead of 
looking at the architecture from the perspective of interoperability, one could easily go a few 
levels deeper in detail to look at the architecture from the perspective of integration. 
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Systems with improper documentation may have to be reverse engineered to complete 
this step. Although reverse engineering can be a costly endeavor, it is vitally important to the 
remainder of the architecture that a comprehensive understanding of system capabilities is 
available within the architecture. If a completely new domain is being architected, this step may 
not be necessary; however, it can be used to conduct market research and document 
commercial technologies that may be available when it comes time to develop and field systems. 
The result of this step will be a standardized repository for all system capabilities and interfaces. 
These results should be made available to all architects within the domain, as system 
capabilities do not change with functional areas. 


To continue the storyboarded example, a hypothetical ‘market analysis’ was completed 
to determine what systems are available that can meet the objectives defined in the operational 
perspective of our role-centric architecture. Candidate systems were identified and system 
capabilities were matched up against the activities defined in the previous step. If a system was 
capable of achieving this activity, this was documented as a system function. If a system was 
capable of exchanging information with another system, this was documented as a system 
information exchange capability (SIEC). Lik e their related IL Rs, SIECs are documented 
between system pairs and associated with an information element. The ‘results’ of this market 
survey are included in the tables below: 



System Functions 

System Information Exchange Capabilities 

Sensl 

Al-1, Al-2 

Contl(IDl) Conti(ID2) 

Sens2 

Al-1 

Cont2(IDl) Cont3(IDl) 

Sens3 

Al-2 

Conti(ID2) Cont2(ID2) 

Sens4 

Al-2 

Cont3(ID2) 

Sens5 

Al-3, Al-4 

Conti(FDl) Conti(FD2) 

Sens6 

Al-3 

Conti(FDl) Cont2(FDl) 

Sens7 

Al-5 

Conti (FDl) Cont2(FDl) 


Table 14. Sensor Market Survey Results 
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System Functions 

System Information Exchange Capabilities 

Conti 

A4-1, A4-2, A3, A2- 
3 

Sens 1 (ID 1) Sensl(ID2) Sens6(FDl) 
Sens5(FDl) Sens5(FD2) Sens7(FLl) 

Cont2 

A4-1, A4-2, A2-1, 
A2-3 

Sens2(IDl) Sens3(ID2) Sens6(FDl) 
Mon2(ID3) Sens2(IDl) Sens5(FD2) 
Sens5(FDl) 

Cont3 

A4-1, A4-2, A2-1, 

A3 

Sens 1 (ID 1) Sens2(IDl) Sens7(FLl) 
Sens4(ID2) Mon2(ID3) Sens6(FDl) 


Table 15. System Controller Market Survey Results 



System Functions 

System Information Exchange Capabilities 

Monl 

A2-3 

Police 1(ID6) Firel(FD5) 

Mon2 

A2-3 

Cont2(ID3) Cont3(ID3) 

Police2(ID6) Fire2(FD5) 


Table 16. Monitoring Service System Market Survey Results 



System Functions 

System Information Exchange Capabilities 

Police 1 

A6 

Monl(ID6) 

Police2 

A6 

Mon2(ID6) 

Firel 

A6 

Monl(FD5) 

Fire2 

A6 

Mon2(FD5) 


Table 17. External Agency System Market Survey Results 



System Functions 

System Information Exchange Capabilities 

Phone 

A5-2, A6 

Monl(ID4) Mon2(ID4) 

Monl(ID5) Mon2(ID5) 

Monl(FD4) Mon2(FD4) 

Monl(FF3) Mon2(FF3) 


Table 18. Homeowner System Market Survey Results 


There are a few items of particular note as a result of this market survey. First, is to 
note that while external agency ‘systems’ may not be under the control of the functional area 
manager, it is important that the capabilities of these systems are also captured, as 

communication with them is imperative to the completion of the mission. For instance, these 

43 
















































systems may be the 911 emergency response system and, perhaps, a direct feed from the 
security service into a town’s police or fire department. Later, when selecting which monitoring 
service systems to implement for the functional area, it will be important to know which of these 
systems support the direct feed and which rely on another system—namely the 911 response 
operators and the phone company. 

Second, even communications networks that might be considered global and 
standard—like the phone system—need to be documented. If activities within the functional 
area are expected to be reliant on these systems, that reliance needs to be captured. For 
instance, it is lik ely that in any of the circumstances in which the homeowner needs to be 
contacted, that they will first be contacted by phone. Completion of these activities is reliant on 
that phone and phone system, and, therefore, this needs to be documented within the 
architecture. 

Third, note that each interface is documented with two system ident if iers and an TH R 
identifier. Furthermore, each interface is listed twice, once under each system endpoint. Even 
in this very simple example, the more central systems have as many as 8 SIECs associated with 
them. In larger functional areas with many more systems, this number can grow exponentially. 
This highlights the need for a centralized database to track these relationships and dependencies. 
Without it, it would be impossible to maintain consistency and currency within the architecture. 

Lastly, note that each system function and interface is defined in terms of the operational 
architecture established in Step Two. Without this, the information captured in the architecture 
is virtually useless, as it will become impossible to track capabilities to requirements (especially 
as the architecture grows.) 

a. System-Centric Architecture - Capabilities Perspective 

In this step, the focus was on the relationships between systems, system 
functions and system information exchange capabilities. These objects and associations can be 
added to the proposed architectural data model as shown in Figure 7. 
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It is important to note in the data model that while there can be any 
combinations of relationships between systems and activities, that a system function is a mapping 
of only one system to one activity. Also, note that while an IER was an association between 
two activities described by an information element , an SIEC is an association between two 
system functions (which are in themselves associations between a system and an activity ) 
described by and Information Element. Therefore, the SIEC is an association in which five 
previously defined objects take part. And, because an SIEC has a direct attachment to the 
Information Element and not the IER , it is possible to document capabilities that are not driven 
by a documented requirement. This will not be true on the requirements side of the system¬ 
centric architecture. 



Figure 7. Data Model Relationship between Operational Perspective, Role-Centric and Capabilities 

Perspective, System-Centric Architectures 
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In Step Three, the relationship between systems, system functions, and system 
information exchange capabilities was explained. These objects and their associations 
collectively are known as the Capabilities Perspective of the System-Centric Architecture. 
System-centric architectures are intended to be of greatest use to the developer, integrator, and 
other stakeholders of the domain that are direcdy responsible for a systems’ implementation. 
Hence, they are focused upon a particular system, as opposed to a functional area. 

In the next step, this information will be analyzed to determine which of today’s 
systems can meet the roles that were identified previously in Step Two. 

4. Step Four: Determine What Systems are Capable of Meeting What 

Roles 

The next step is to compare the capabilities of today’s systems to the activities outlined 
in the Role-centric architecture to answer two primary questions: 

1) Which of today’s systems are capable of meeting operational requirements as 
outlined in the role-centric architecture? 

2) Where are there gaps in current capabilities for which new systems or capabilities 
must be procured? 

To complete this step, the activities each system is capable of performing and the 
interfaces they can support are compared to the activities and IF Rs that were outlined for each 
node. Systems are then assigned to nodes based on those comparisons. 

It is possible for systems to be assigned to multiple nodes, even within the same 
functional area. Additionally, multiple systems may be capable of fulfilling any one role and 
many systems may be tasked to multiple functional areas. For instance, in the functional area of 
Close Air Support, there is a role called Air Interdictor—a plane that can attack targets on the 
ground. There are many planes in the current inventory capable of fulfilling this role: A-10, 

AC-130, F-14, F-15, F-16, F-18, etc. Furthermore, any one of these aircraft could be called 
in to fu lfill a role in another functional area, such as Combat Air Patrol, Air-to-Air Superiority, 
or Force Protection. This is expected and perfectly acceptable, especially as we acquire more 
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multi-role weapons systems. In fact, it is important to understand all the systems that are 
capable of fulfilling each role, and all the other systems that could be fielded together to achieve 
a functional area in order for the full scope of interoperability requirements to be realized. The 
end result of this step will be an assignment of systems (or groups of systems) to roles and an 
analysis of what requirements cannot be met by today’s systems. 

a. Assigning Systems to Roles 

In the ongoing example of Home Security, systems were assigned to the roles 
outlined in the role-centric architecture based on the activities they could perform. For example, 
Sensor 1 is capable of acting as both a Door Sensor and a Window Sensor, and is, therefore, 
assigned to both roles. However, Sensor 2 can only be used as a Door Sensor, and so is only 
assigned to the one role. Using this type of analysis, systems were assigned to roles in the 
following manner: 



System Functions 

System Information Exchange Capabilities 

Roles 

Sensl 

Al-1, Al-2 

Contl(IDl) Conti(ID2) 

ID-Door Sensor 

ID-Window Sensor 

Sens2 

Al-1 

Cont2(IDl) Cont3(IDl) 

ID-Door Sensor 

Sens3 

Al-2 

Conti(ID2) Cont2(ID2) 

ID-Window Sensor 

Sens4 

Al-2 

Cont3(ID2) 

ID-Window Sensor 

Sens5 

Al-3, Al-4 

Contl(FDl) Conti(FD2) 

FD-Smoke Detector 

FD-Heat Detector 

Sens6 

Al-3 

Contl(FDl) Cont2(FDl) 

FD-Smoke Detector 

Sens7 

Al-5 

Conti(FL1) Cont3(FLl) 

FL-Flood Sensor 


Table 19. Sensor Assignments to Roles 



System Functions 

System Information Exchange Capabilities 

Roles 

Conti 

A4-1, A4-2, A3, 
A2-3 

Sens 1 (ID 1) Sensl(ID2) Sens6(FDl) 
Sens5(FDl) Sens5(FD2) Sens7(FLl) 

ID-System Controller 

FD-System Controller 

FF- System Controller 

Cont2 

A4-1, A4-2, 

A2-1, A2-3 

Sens2(IDl) Sens3(ID2) Sens6(FDl) 
Mon2(ID3) Sens2(IDl) Sens5(FD2) 
Sens5(FDl) 

ID-System Controller 

FD-System Controller 
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Cont3 

A4-1, A4-2, A2- 

Sens 1 (ID 1) Sens2(IDl) Sens7(FLl) 

ID-System Controller 


1, A3 

Sens4(ID2) Mon2(ID3) Sens6(FDl) 

FD-System Controller 

FL-System Controller 


Table 20. System Controller Assignments to Roles 



System Functions 

System Information Exchange Capabilities 

Roles 

Monl 

A2-3 

Police 1(ID6) Firel(FD5) 

I-Monitoring Service 

F-Monitoring Service 

FL-Monitoring Service 

Mon2 

A2-3 

Cont2(ID3) Cont3(ID3) 

Police2(ID6) Fire2(FD5) 

I-Monitoring Service 

F-Monitoring Service 

FL-Monitoring Service 


Table 21. Monitoring System Assignments to Roles 


In all lik elihood, not all the systems will be capable of performing every activity 
and of supporting every interface. When it comes time to implementing actual combinations of 
systems, many considerations may affect the final decision. For instance, in the Fire Detection 
Functional Area, Sensor 5 is only capable of talking to Controller 1 and, likewise, Sensor 6 is 
only capable of communicating with Controller 2. However, Sensor 5 is also the only sensor 
capable of sensing heat. It is also important when making these assignments to also remember 
that a parent system, by definition, brings with it all of its children. Additionally, it is of note that 
Controller 2 was not assigned to the Flood Detection functional area. Although a ‘System 
Controller’ by name (and, therefore, lik ely to be considered for this role), the analysis revealed 
that Controller 2 did not support any of the flood detection activities or interfaces and, 
therefore, was not well suited to that functional area. 

There are many areas where tradeoffs will have to be considered when making 
a final implementation decision. But, this data-driven approach to architecture will provide the 
necessary information to make those decisions. 
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b. Role-Centric Architecture - Systems Perspective 

This mapping of systems to roles, based on the activities they can perform has provided a link 
between the Operational Perspective of the Role-Centric Architecture and the Capabilities 
Perspective of the System-Centric Architecture. (See Figure 8) 

Hie only change to the data model is the adding of an unattributed association 
between a system and a role, which is depicted in Appendix A and subsequent views of the 
model. Additionally, it is important to recognize that there is no difference in the data contained 
in the Capabilities Perspective of the System-Centric architecture and Figure the Systems 
Perspective of the Role-Centric Architecture. In fact, the exact subset of data makes up both. 
Hie difference is rather in the manner in which the data is viewed and used. In the Capabilities 
Perspective, the focus is on a single system and all its capabilities regardless of functional area. 



Figure 8. Relationship between Role-Centric and System-Centric Architectures (Partial) 


In the Systems Perspective of the Role-Centric Architecture, the focus is on the 
functional area and the combined capabilities of all the systems that have been assigned to that 
functional area. 
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With systems assigned to roles, the operational requirements of those roles can 
be levied in turn back onto the systems community to fill in the gaps in capability that were 
revealed during the analysis. 

5. Step Five: Levy Interoperability Requirements on Systems 

At this point, the architect has successfully identified the needs of his functional area (in 
terms of roles, activities, and IERs), the capabilities of available systems (in terms of systems, 
functions, and SIECs), and done the first part of analysis to determine how his current systems 
meet the needs of his functional area. It is now necessary to close the loop by determining 
which of his operational needs could not be met by today’s systems and levying those back on 
system developers in terms of tomorrow’s requirements. As has been discussed previously, 
operational interoperability requirements determine system interoperability requirements [3]. 

But this determination could not have been made properly without the work of the previous four 
steps. 

To complete this step, the systems will inherit the interoperability requirements of the 
activities to which they are assigned. This becomes the basis of all future interoperability 
requirements and testing. Operational activities get levied on systems in the form of system 
requirements. And IERs get levied on systems in the form of System Information Exchange 
Requirements. 

In functional areas where there are multiple systems assigned to roles, it is important to 
propagate the entire spectrum of combinatory possibilities as requirements. For instance, the 
role of the Air Interdictor in the Close Air Support functional area was previously discussed. If 
this role had an IR R with another role in the functional area, suppose an Airborne Command 
Node. Then all the aircraft assigned to the Air Interdictor role (A-10, AC-130, F-14, F-15, F- 
16, F-18) would be given that IF R with all the aircraft assigned to the Airborne Command role 
(AWACS, P-3, JSTARS), for a total of 18 SIERs generated from the 1 IER. 

Gap analyses can be lengthy and complex. One benefit of the centralized database is 
that it allows tools to be developed that can accomplish this gap analysis automatically. This 
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step ultimately results in documented operational requirements for all the systems in the domain 
and, possibly, an identification of need for additional systems. 


Continuing with the example of home security, a gap analysis was performed of current 
system capabilities versus requirements to identify any holes. 



Roles 

Sys Reqts 

Sys Funcs 

SIERs 

SIECs 

Conti 

ID-System Controller 
FD-System Controller 
FL-System Controller 

A2-1 

A3 

A4-1 

A4-2 

A2-3 

A4-1 

A4-2 

A3 

A2-3 

Sens 1 (ID 1) 

Sens2(IDl) 

Sensl(ID2) 

Sens3(ID2) 

Sens4( ID2) 

Monl(ID3) 

Mon2(ID3) 

Sens5(FDl) 

Sens6(FDl) 

Sens5(FD2) 

Monl(FD3) 

Mon2( FD3 ) 

Firel(FD5) 

Fire2(FD5) 

Sens7(FLl) 

Monl(FL2) 

Mon2(FL2) 

Sens 1 (ID 1) 

Sensl(ID2) 

Sens6(FDl) 

Sens5(FDl) 

Sens5(FD2) 

Sens7(FLl) 

Cont2 

ID-System Controller 
FD-System Controller 

A2-1 

A3 

A4-1 

A4-2 

A2-3 

A4-1 

A4-2 

A2-1 

A2-3 

Sens 1 (ID 1) 

Sens2(IDl) 

Sensl(ID2) 

Sens3(ID2) 

Sens4(ID2) 

Monl(lD3) 

Mon2(ID3) 

Sens5(FDl) 

Sens6(FDl) 

Sens5(FD2) 

Monl(FD3) 

Mon2( FD3 ) 

Firel(FD5) 

Fire2(FD5) 

Sens2(IDl) 

Sens3(ID2) 

Sens6(FDl) 

Mon2(ID3) 

Sens2(IDl) 

Sens5(FD2) 

Sens5(FDl) 

Cont3 

ID-System Controller 
FD-System Controller 

A2-1 

A3 


Sens 1 (ID 1) 
Sens2(IDl) 

Sens 1 (ID 1) 
Sens2(IDl) 
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FL-System Controller A4-1 A2-1 Sensl(ID2) Sens7(FLl) 

A4-2 A3 Sens3(ID2) Sens4(ID2) 

A2-3 Sens4(ID2) Mon2(ID3) 

Monl(ID3) Sens6(FDl) 
Mon2(ID3) 

Sens5( FD1) 

Sens6(FDl) 

Sens5(FD2) 

Monl(FD3) 

Mon2(FD3) 

Firel(FD5) 

Fire2(FD5) 

Sens7(FLl) 

Monl(FL2) 

__ Mon2(FL2) _ 

Table 22. System Controller Gap Analysis 



Roles 

System 

Requirements 

System 

Functions 

System 

Information 

Exchange 

Requirements 

System 

Information 

Exchange 

Capabilities 

Sensl 

ID-Door Sensor 

ID-Window Sensor 

Al-1 

Al-2 

Al-1 

Al-2 

Contl(IDl) 

Conti (ID2) 
Cont2(IDl) 
Cont2(ID2) 
Cont3(IDl) 
Cont3(ID2) 

Contl(IDl) 

Conti (ID2) 

Sens2 

ID-Door Sensor 

Al-1 

Al-1 

Conti (ID 1) 
Cont2(IDl) 
Cont3(IDl) 

Cont2(IDl) 

Cont3(IDl) 

Sens3 

ID-Window Sensor 

Al-2 

Al-2 

Conti (ID2) 
Cont2(ID2) 
Cont3(ID2) 

Conti (ID2) 
Cont2(ID2) 

Sens4 

ID-Window Sensor 

Al-2 

Al-2 

Conti (ID2) 
Cont2(ID2) 
Cont3(ID2) 

Cont3(ID2) 

Sens5 

FD-Smoke 

Detector 

FD-Heat Detector 

Al-3 

Al-4 

Al-3 

Al-4 

Conti (FDl) 
Conti (FD2) 
Cont2(FDl) 
Cont2(FD2) 

Conti (FDl) 

Conti (FD2) 
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Cont3(FDl) 

_ Cont3(FD2) _ 

Sens6 FD-Smoke Al-3 Al-3 Contl(FDl) Contl(FDl) 

Detector Cont2(FDl) Cont2(FDl) 

_ Cont3(FDl) _ 

Sens7 FL-Flood Sensor Al-5 Al-5 Contl(FLl) Contl(FLl) 

___ Cont3(FLl) Cont3(FLl) 

Table 23. Sensor Gap Analysis 


Roles System System SIERs SIECs 

Requirements Functions 

Monl ID-Monitoring Service A2-2 A2-3 Contl(ID3) Policel(ID6) 

FD-Monitoring Service A2-3 Cont2(ID3) Firel(FD5) 

FL-Monitoring Service A5-1 Cont3(ID3) 

A5-2 Phone(ID4) 

Phone(ID5) 

Police 1(ID6) 

Police2(ID6) 

Conti (FD3) 

Cont2(FD3) 

Cont3(FD3) 

Phone(FD4) 

Conti (FL2) 

Cont3(FL2) 

Phone(FL3 ) 

Mon2 ID-Monitoring Service A2-2 A2-3 Conti(ID3) Cont2(ID3) 

FD-Monitoring Service A2-3 Cont2(ID3) Cont3(ID3) 

FL-Monitoring Service A5-1 Cont3(ID3) Police2(ID6) 

A5-2 Phone(lD4) Fire2(FD5) 

Phone(ID5) 

Police 1(1D6) 

Police2(ID6 ) 

Conti (FD3) 

Cont2( FD3 ) 

Cont3(FD3) 

Phone( FD4) 

Conti (FL2) 

Cont3(FL2) 

Phone( FL3 ) 


Table 24. Monitoring System Gap Analysis 
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There are many observations that can be made as a result of this gap analysis. In most 
cases, the analysis has shown holes between our requirements and capabilities that can be levied 
as future requirements on our systems. However, there are a few exceptions: 

1) In the case of the monitoring service systems, it is noted there are several activities 
that are currently not being met by the system capabilities. However, upon further examination, 
activities 5-1 and 5-2 are decision-making activities to be accomplished by the role of 
monitoring service, and are not necessarily system activities. These need not be levied on the 
systems for future development unless it is desired that the systems start making these decisions 
in the future (which may or may not be likely.) 

2) Also looking at the monitoring service systems, there are SIECs listed that do not 
match up against any known S TF Rs. For instance, the ability to communicate with the Fire 
Department is desired at the System Controller level. However, this is an existing capability 
regardless of requirement. Therefore, it is perfectly valid for it to be documented in the 
architecture. And, in this case, would be useful for the architect to know as none of his system 
controllers are currently capable of completing this task. (It may be possible to re-route this 
information through the monitoring service as an interim until a system fix can be made at the 
controller level.) This, again, highlights one of the advantages of this approach to systems 
requirements and tracking. 

3) With regards to the sensors, the analysis shows that while the sensors meet all their 
functional requirements, they lack severely in the interoperability capabilities. This is the 
intended outcome of this methodology—to clearly show where there are systems currently in 
the field, conducting tasks, that do not meet the interoperability needs of today’s users. 

The solution is simple: the DoD needs a structured methodology by which to define 
these interoperability requirements, levy them on systems and track them through 
implementation. 

Through this last step, the feedback between operational requirements and system 
requirements is complete. Using the information gathered regarding the capabilities of today’s 
systems, a thorough understanding of where system shortfalls lie, and where requirements are 


54 



lacking has been gained. The relationship between the Role-Centric and System-Centric 
architectures is complete. 


The mapping of activities and I H Rs back onto systems has resulted in two additions to 
the data model: system requirements and system information exchange requirements. 
Similar to a system function, the system requirement is an association between an activity 
and a system. Likewise, an SIER is a mapping between and IER and two system 
requirements. The completed data model is located in Appendix A. 


Role-Centric Architecture System-Centric Architecture 


Operational 


System View 

View 



Role 

— 

System 

Activity 


System Function 

IER 


SIEC 


Information I 

Exchange Requirements are levied on systems based 
on the roles the system is expected to perform 


System capabilities are used to determine what 
requirements/roles can be met by today’s 

| systems 


Requirements 


Capabilities 

View 


View 

System 

— 

System 

Requirement 


System Function 

SIER 


SIEC 


Figure 9. Relationship between Role-Centric and System-Centric Architecture (Complete) 


6. Step Six: Prepare for the Future 

The final step of this methodology is a continuous activity. These proposed 
architectures and methods represent living representations of the domain and should maintained 
over time to reap optimal benefits from the architectures. But, in order to accomplish this, the 
elements of the architecture must be attributed to facilitate the concept of time. Through time- 
phasing, the architecture can be adapted to document future requirements, future and planned 
capabilities, and can help align software systems that are in orthogonal spirals of the spiral 
development process. 
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a. Time-Phasing Requirements 

Each element of the proposed architecture has the ability to be attributed with a 
period of time over which it is valid. Requirements generally will not change as often as systems 
do, especially in the defense world, as it has often been argued that new technologies do not 
fundamentally change the way we fight wars. However, new initiatives like Joint Vision 2010, 
Joint Vision 2020, C4I for the Warrior, and other programs that look at how we can change the 
way we fight based on the capabilities of today’s systems drive us towards new requirements 
for our systems of the future. 

These requirements can be captured in the same architecture used to document 
today’s requirements by using a date stamp on each architectural element. In this way, system 
developers will be able to anticipate the requirements of their systems one, two, or even 10 to 
20 years down the line. One suggestion for the defense and government sectors is that 
requirements be adjusted around the POM cycle—a five-year cycle through which future 
budgets are planned. This would provide a mechanism to better align programmatic dollars 
where the requirements are going to be. 

In the process of time-phasing requirements, there are two types of 
requirements that must be reviewed. First are the operational requirements of the domain or 
functional area—those that were captured in the operational perspective of the role-centric 
architecture. When phasing these requirements, the architect would approach for a more 
‘visionary’ stance. How should this functional area be conducted in 5 years? How can we 
better align these activities to fight the wars of the future? What benefits can I reap from 
the systems that are coming down line to further decentralize my execution and eliminate 
multiple command and communication nodes? These are the types of considerations that 
can be made when looking at the role-centric architectures of tomorrow. 

There are also those operational requirements as they were levied on the 
systems, in the forms of system requirements and SIERs. It is unlikely that the system 
requirements will have the same lifespan as their operational parents; again as our systems are 
likely to change more often than the way we conduct current operations. When phasing these 
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requirements, the architect must take an approach that mixes ‘vision’ with ‘reality.’ For 
instance, the architect might decide he can better serve a functional area with the introduction of 
a new multi-role fighter in 5 to 7 years—one that takes on many of the activities outlined in the 
architecture to reduce the number of fielded systems. This is an example of more visionary 
thinking. However, the architect must also consider that the new Joint Strike Fighter (JSF), for 
instance, is going to replace other aging aircraft; so requirements that used to be on the F-16 
and F-18, for instance, need to be moved to the JSF at the appropriate time in the future. This 
is an example of reality-based phasing. 

Incorporating a time-phased approach to requirements into part of the Home 
Security example, we might decide that in the Intruder Detection Functional Area, that today’s 
requirements of door and window intrusion detection are sufficient for today; but, in ten years it 
will be necessary to also detect wireless cyber- intrusion. In that case, the operational 
requirements of the functional area would be updated to include a new activity with all the 
necessary IERs. 



Description 

Dates Valid 

Al. 

Maintain Physical Security 

200201 - 202201 

Al-1. 

Detect Door Opening 

200201 - 202201 

Al-2. 

Detect Window Opening 

200201 - 202201 

Al-3. 

Detect Smoke 

200201 - 202201 

Al-4. 

Detect Heat 

200201 - 202201 

Al-5. 

Detect Flood 

200201 - 202201 

A1-6. 

Detect Cyber-Intrusion 

201201 - 202201 

A2. 

Make External Notifications 

200201 - 202201 

A2-1. 

Contact Monitoring Service 

200201 - 202201 

A2-2. 

Contact Homeowner 

200201 - 202201 

A2-3. 

Contact Police 

200201 - 202201 

A2-4. 

Contact Fire Department 

200201 - 202201 

A3. 

Activate Alarm 

200201 - 202201 

A4. 

System Operation 

200201 - 202201 

A4-1. 

Arm System 

200201 - 202201 

A4-2. 

Disarm System 

200201 - 202201 

A5. 

Situation Analysis/Decision Point 

200201 - 202201 
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A5-1. 

Decide if Homeowner Intervention is Required 

200201 - 202201 

A5-2. 

Decide if Emergency Response is Required 

200201 - 202201 

A6. 

Emergency Response 

200201 - 202201 

A6-1. 

Investigate/Respond to Security Alarm 

200201 - 202201 

A6-2. 

Respond to Fire Alarm 

200201 - 202201 


Table 25. Updated Activity List 


■ 

Originating 

Role 

Originating 

Activity 

Receiving 

Role 

Receiving Activity 

Information 

Element 

Dates 

Valid 

ID 

Door 

Al-1. Detect 

System 

A3. Activate 

Door Status 

200201 

1 

Sensor 

Door Opening 

Controller 

Alarm 


202201 

ID 

Window 

Al-2. Detect 

System 

A3. Activate 

Window 

200201 

2 

Sensor 

Window Opening 

Controller 

Alarm 

Status 

202201 

ID 

System 

A2-1. Contact 

Monitoring 

A5-1. 

Alarm 

200201 

3 

Controller 

Monitoring 

Service 

Service 

Homeowner 

Intervention 

Decision 

Notification 

202201 

ID 

Monitoring 

A2-2. Contact 

Homeowner 

A5-2. Emergency 

Alarm 

200201 

4 

Service 

Homeowner 


Intervention 

Decision 

Notification 

202201 

ID 

Homeowner 

A5-2. Emergency 

Monitoring 

A2-3. Contact 

Intervention 

200201 

5 


Intervention 

Decision 

Service 

Authorities 

Decision 

202201 

ID 

Monitoring 

A2-3. Contact 

Emergency 

A6. Emergency 

Alarm 

200201 

6 

Service 

Authorities 

Response 

Agency 

Response 

Notification 

202201 

ID 

Cyber 

A1-7. Detect 

System 

A3. Activate 

Cyber 

201201 

7 

Sensor 

Cyber-Intrusion 

Controller 

Alarm 

Attack 

Notification 

202201 

ID 

System 

A2-1. Contact 

Monitoring 

A5-1. 

Cyber 

201201 

8 

Controller 

Monitoring 

Service 

Service 

Homeowner 

Intervention 

Decision 

Attack 

Notification 

202201 


Table 26. Updated Intruder Detection IER List 
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Following the update within the role-centric architecture, it is necessary to 
ensure that the changes are considered for the system-centric architecture, as well. It is 
assumed that the current door and window sensors are not well suited to detect cyber attacks, 
and therefore, it will be necessary to identify a requirement in the architecture for a new start 
system and correcdy assign the system requirements and SIERs, accordingly. In this case, the 
architect has chosen to also review the time stamps of current system requirements. The result 
follows: 



Roles 

System 

Reqts 

Dates Valid 

SIERs 

Dates Vahd 

Sensl 

ID-Door Sensor 

ID-Window 

Sensor 

Al-1 

Al-2 

200201 - 202201 

200201 - 202201 

Contl(IDl) 
Conti (ID2) 
Cont2(IDl) 
Cont2(ID2) 
Cont3(IDl) 
Cont3(ID2) 

200201 - 202201 

200201 - 202201 

200407 - 202201 

200407 - 202201 

200201 -201010 

200201 -201010 

Sens2 

ID-Door Sensor 

Al-1 

200201 - 202201 

Contl(IDl) 

Cont2(IDl) 

Cont3(IDl) 

200201 - 202201 

200407 - 202201 

200201 -201010 

Sens3 

ID-Window 

Sensor 

Al-2 

200201 - 202201 

Conti (ID2) 
Cont2(ID2) 
Cont3(ID2) 

200201 - 202201 

200407 - 202201 

200201 -201010 

Sens4 

ID-Window 

Sensor 

Al-2 

200201 - 202201 

Conti (ID2) 
Cont2(ID2) 
Cont3(ID2) 

200201 - 202201 

200407 - 202201 

200201 - 20101 

Sens5 

FD-Smoke 

Detector 

FD-Heat Detector 

Al-3 

Al-4 

200201 - 202201 

200201 - 202201 

Conti (FD1) 
Conti (FD2) 
Cont2(FDl) 
Cont2(FD2) 
Cont3(FDl) 
Cont3(FD2) 

200201 - 202201 

200201 - 202201 

200407 - 202201 

200407 - 202201 

200201 -201010 

200201 -201010 

Sens6 

FD-Smoke 

Detector 

Al-3 

200201 - 202201 

Conti (FDl) 
Cont2(FDl) 
Cont3(FDl) 

200201 - 202201 

200407 - 202201 

200201 -201010 

Sens7 

FL- Flood Sensor 

Al-5 

200201 - 202201 

Conti (FL1) 
Cont3(FLl) 

200201 - 202201 

200201 -201010 
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New 

ID-Cyber Sensor 

Al-6 

201201 - 202201 

Conti (ID7) 

201201 - 202201 





Cont2(ID7) 

201201 - 202201 


Table 27. Sensor Systems with Time-Phased Requirements 


In this scenario, the new ‘cyber-sensor’ requirements were added to the 
system-centric architecture under the system name ‘New,’ to clearly point out the emerging 
requirement. Because the system is not expected to be out for another 10 years, the dates and 
the previously assigned activities and IF Rs were adjusted accordingly. Additionally, a brief 
analysis of the System Controller situation revealed that while Controller 1 was available for the 
lifetime of the architecture (Jan 2002 - Jan 2022), Controller 2 would not be out on the market 
until July 2004 and Controller 3 was anticipated to go End-of-Life in October 2010. With this 
in mind, it was determined there was no need to establish a requirement for the Cyber-Sensor 
to interoperate with Controller 3 as the controller would no longer be available by the time the 
cyber-sensor was ready to be fielded. The IER remains valid over the entire lifetime of the 
architecture, as the requirement itself has not changed. However, when this is mapped to a 
specific system (as an SIER ,) the dates may change depending on the lifetime and maturity of 
that system. 

This is just one example of the power time-stamping architectural elements can 
yield. To be able to capture and maintain this kind of information is to provide the tools to see 
the evolution of requirements over time and greatly facilitate better decision-making. 

b. Time-Phasing Capabilities 

These lessons can also be applied to the development community. Software 
systems, more than any other fielded technologies, are vulnerable to change and changing 
requirements. The current DoD acquisition lifecycle expects software systems to update every 
18 months, and the spiral development cycle is pushing that down to 6. Regardless, as systems 
are put on contract, future requirements are typically not well understood, and as a result, cost 
overruns due to poor requirements definition abound. As the DoD moves forward with time- 
phasing requirements, a methodology must be in place for the acquisition community to also 
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incorporate these concepts into the development cycle, and be able to feed back their progress 
to the operators and requirements community. 

Time-phasing capabilities can provide two key pieces of information: when a 
capability will be available, and when it is going away. The latter is especially important to help 
sustain current capabilities. As discussed previously, interoperability is a state. And being able 
to track that condition of that state over time is imperative. By knowing when systems are going 
to be discontinued, or interfaces no longer supported, that state of interoperability can be 
maintained more easily. 

The example of home security continues to show how time-phasing capabilities 
is worked into the architecture. The below table shows how different systems, despite the fact 
that they may have a valid requirement over an extended period of time, may have to implement 
this requirement into capability differently. This information is vital to those planners determining 
what systems are to be fielded, especially in deciding sets of interoperable systems that must be 
deployed. 



Roles 

SIERs 

Dates Valid 

SIECs 

Dates Valid 

Sensl 

ID-Door 

Contl(IDl) 

200201 - 202201 

Contl(IDl) 

200201-202201 


Sensor 

Conti (ID2) 

200201 - 202201 

Conti (ID2) 

200201-202201 


ID-Window 

Cont2(IDl) 

200407 - 202201 

Cont2(IDl) 

200407-202201 


Sensor 

Cont2(ID2) 

200407 - 202201 

Cont2(ID2) 

200407-202201 



Cont3(IDl) 

200201 - 201010 

Cont3(IDl) 

200601-201010 



Cont3(ID2) 

200201 - 201010 

Cont3(ID2) 

200601-201010 

Sens2 

ID-Door 

Contl(IDl) 

200201 - 202201 

Contl(IDl) 

200509-201105 


Sensor 

Cont2(IDl) 

200407 - 202201 

Cont2(IDl) 

200407-201105 



Cont3(IDl) 

200201 - 201010 

Cont3(IDl) 

200201-201010 

Sens3 

ID-Window 

Conti (ID2) 

200201 - 202201 

Conti (ID2) 

200201-202201 


Sensor 

Cont2(ID2) 

200407 - 202201 

Cont2(ID2) 

200401-202201 



Cont3(ID2) 

200201 - 201010 



Sens4 

ID-Window 

Conti (ID2) 

200201 - 202201 

Conti (ID2) 

200301-202201 


Sensor 

Cont2(ID2) 

200407 - 202201 





Cont3(ID2) 

200201 - 201010 

Cont3(ID2) 

200201-201010 
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Sens5 

FD-Smoke 

Detector 

FD-Heat 

Detector 

Conti (FDl) 
Conti (FD2) 
Cont2(FDl) 
Cont2(FD2) 
Cont3(FDl) 
Cont3(FD2) 

200201 - 202201 

200201 - 202201 

200407 - 202201 

200407 - 202201 

200201 - 201010 

200201 - 201010 

Conti (FDl) 
Conti (FD2) 
Cont2(FDl) 
Cont2(FD2) 
Cont3(FDl) 
Cont3(FD2) 

200201-201011 

200201-201011 

200601-202201 

200601-202201 

200201-201010 

200201-201010 

Sens6 

FD-Smoke 

Detector 

Conti (FDl) 
Cont2(FDl) 
Cont3(FDl) 

200201 - 202201 

200407 - 202201 

200201 - 201010 

Conti (FDl) 
Cont2(FDl) 

200201-202201 

200407-202201 

Sens7 

FL-Flood 

Sensor 

Conti (FL1) 
Cont3(FLl) 

200201 - 202201 

200201 - 201010 

Conti (FLl) 
Cont3(FLl) 

200201-202201 

200201-201010 

New 

ID-Cyber 
Sensor 

Conti (ID7) 
Cont2(ID7) 

201201 - 202201 

201201 - 202201 

Conti (ID7) 
Cont2(ID7) 

201201-202201 

201201-202201 


Table 28. Sensor Systems with Time-Phased Capabilities 


The time-phased requirements reveal the development plans of the various 
system developers and provide planners that additional piece of information to make an 
informed decision about which systems will be available to the warfighter when they deploy at 
various times in the future. For instance, this attribute reveals that Sensor 2 is going off the 
market in May 2011. Any reliance on this sensor after that point would have to be 
compensated. In addition, the different sensors implement the required interfaces at different 
times. Some have no intentions of implementing some of the interfaces at any time. At any one 
future date, a different set of sensor-controller pairs might be needed to complete the needs of 
the functional area. 

These scenarios are not only plausible, they are extremely realistic, especially as 
the DoD grows more reliant on Commercial-Off-the-Shelf (COTS) products in which the DoD 
may not be the primary customer. Hie DoD cannot assume that all its requirements will be 
implemented in a COTS-based world. Commercial industry has become the forcing function 
for new technologies, and many vendors will choose to drive with it, rather than step backwards 
to meet defense needs. 

Overall, it is the responsibility of the system developer to maintain the data on 
their systems. And, therefore, the onus is put on the acquisition community to determine when a 
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capability will be available and how it will be supported. If it is decided that a system will be 
replaced, this process facilitates a smoother transition from the old system to the new by 
allowing for easy conversion of requirements and previously documented interfaces. Today, 
new systems often do not have the luxury of obtaining documentation on the systems they are 
intended to replace. This methodology allays many of those issues. 

c. Satisfying Spiral Development Needs 

DoDD 5000.2 mandates “software development and integration shall follow an 
iterative spiral development process in which continually expanding software versions are based 
on learning from earlier development.” [16] As a result, there are literally thousands of 
disparate software development projects in the DoD today, each spiraling at their own rates, all 
of which must be interoperable with at least one or more of the others, and most of which must 
be integrated into a larger system to be fielded. This creates a constantly changing environment 
in which capabilities are continuously fielded, with little to no mechanism outside each individual 
program office to track their implementations. And there is nothing that provides the individual 
program manager enough information to know if he or she is going to encounter problems with 
the other systems he is required to interact with as each spiral develops. 

Hie popularity of spiral development cycles is one of the modem changes that 
make this type of architectural methodology so necessary. Keeping track of emerging and 
falling capabilities can often be difficult within a program office, much less keeping track of the 
orthogonal spirals of several systems, all of which are attempting to be interoperable. By time¬ 
phasing capabilities in a central repository, it will be easier to determine when information 
exchange capabilities will come on line and give program offices the opportunity to collaborate 
their different schedules in a centra liz ed fashion. 

As such, the proposed methodology provides a foundation for meaningful 
communication not only between the requirements and development communities, but within 
these communities as well, so program managers will have insight into the activities of the other 
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programs with which he must interact. This quality is of most importance to those responsible 
for system integration. 

Currently, many system integrators are handed (particularly) software 
applications to be integrated into their systems with little to no knowledge of what that 
application does, how it will interact with the other components of their system, and how it 
affects the requirements of their system as a whole. Many of them are not even provided a 
consolidated set of requirements for the integrated system, and rather rely on the requirements 
of its components to derive the requirements of the whole. Oftentimes, applications are handed 
to them with little to no forewarning, on constantly changing schedules, to be integrated 
immediately to meet a warfighting need. To have a tool through which the integrator could track 
the separate spiral development cycles of each of his component systems, that provides 
inf ormation on which capabilities are supported in which spiral, and also keeps track of 
interoperability requirements for his integrated system and how those are met by each of the 
component systems, would be absolutely invaluable to those responsible for system integration. 

d. Resource Planning 

Analysis of the completed architecture can aid many other stakeholders besides 
the requirements and development communities. One such area that could benefit from the 
architectural information is the resource planning community. 

As discussed previously, time-phasing of requirements provides additional 
information to those responsible for allocating resources and money to systems. By having 
access to the ‘bigger picture’ of development activities and customer priorities (requirements 
can be attributed with a priority, as well) planners can make better informed decisions about 
where money should be allocated to support the needs of tomorrow’s warfighter. 

Also, the warplanners of today would benefit from this architectural information, 
as well. Today’s planners face the daunting task of determining which systems should be sent to 
battle with our soldiers, sailors, and airmen. There currently exists few tools to help them with 
this task, and as a result, the logistical requirements to send troops to global ‘hot spots’ is 
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staggering. Redundant systems and capabilities are fielded. Systems that cannot communicate 
with each other and sent out to the field while systems that are interoperable stay at home--all 
because there exists no methodology for making informed decisions. 

However, using the proposed architectural methodology, this analysis is already 
accomplished for the warplanner. SIECs reveal which systems can be fielded together and 
where the gaps will be if one system must be chosen over another for external constraints (e.g. 
logistical, availability, fiscal, training, etc.) 

For instance, in the home security example, if it was determined that an 
overseas operation required an intruder detection capability, the warplanner could turn to the 
Intruder Detection functional area to find what the requirements were to complete that operation 
and what systems were capable of performing it. A fairly simple analysis would reveal that 
Controller 2 would not be available until July 2004, and if it were determined that the units 
available to deploy had never been trained on Controller 1, it would be necessary to deploy 
Controller 3. But, to detect window openings, Controller 3 must be deployed with Sensor 4. If 
only Sensor 5 was available, the planner would have to make a decision as to whether to not 
support the “Detect Window Opening” activity, or whether to deploy Controller 1, which does 
support Sensor 5, and make arrangements for in-theater training. 

These are the kin ds of decisions our planners need to make every day. 
Unfortunately, they are currently not provided the necessary tools and information to make the 
best decisions to support the warfighter. The proposed methodology counters that by providing 
the required data in a format that allows the planners to make informed decisions about where 
and how to employ our systems. 

Architectures are living projects, to be maintained over time. Although this thesis 
outlines a Six-Step Approach to creating an architecture, the work is hardly finished there. Any 
or all of these steps can, and should, be reaccomplished as the environment, requirements, or 
systems change to ensure that the most accurate, consistent information is available to all the 
stakeholders at any time. 
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V. BENEFITS OF THE DATA-DRIVEN APPROACH 


Many benefits of the proposed approach to enterprise architecture have been discussed 
in other parts of this thesis. Some of these were directed towards use in the Department of 
Defense and specifically toward systems engineering. In the following pages, some of the more 
general benefits of this approach towards enterprise architecture are discussed. These benefits 
apply to any user of a data-driven architectural approach, be they a definer of requirements, a 
systems integrator, a software developer, or a program manager. 

A. MAINTENANCE 

A data-driven approach to architecture results in an architecture that is easier to 
maintain and update compared to its paper or picture-oriented peers. Consider a mature 
architectural effort, populated with activities, systems, requirements, capabilities, and all the 
information exchanges. As seen in Appendix A, the data elements are extremely dependent on 
each other. If one activity must be renamed, or deleted, it can affect literally hundreds or 
thousands of other architectural elements, depending on the scope of the effort. In a paper- 
based architecture, or even one captured in a non-relational database or spreadsheet, finding all 
the links affected by that one changed activity can be extremely difficult. 

Take, for instance, the home security architecture outlined in Chapter IV. This 
architecture is fairly simple, with few data elements and associations. If it were necessary to 
rename the activity “Notify Monitoring Service” to “Alert Central Office,” using a relational 
database this change would be a simple to change to one field in the table that contains the 
listing of current activities. However, if this were a current architectural effort, working off 
another media, such as PowerPoint pictures or non-relational spreadsheets, this one change 
would need to be propagated through 6 architectures (the role-centric and system-centric 
architectures could not be dynamically linked as the methodology proposes, nor could the 3 
functional areas be contained within a single architecture), changing a total of 3 activities, 8 
IERs, 3 roles, 9 systems, 12 SIECs, 9 system requirements, 6 system functions, and 96 SIERs. 
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This one change in a relational database would require a total of 146 separate changes to keep 
an architecture that was not data-driven current. 

With this, an architecture captured in a database is not only easier to maintain, but is 
also cheaper. Coordination of paper copies of the architectural views is timely and expensive. 
Currently, ORD reviews in the DoD can take as long as 6-12 months, sometimes longer, 
depending on the size and complexity of the ORD and the scope of the changes. Propagation 
of even simple changes through paper documents is time-consuming and redirects valuable man¬ 
hours from more important tasks. Using a data-driven approach, changes can be coordinated 
electronically using relatively simple tools to control and manage updates. 

B. DATA CONFIGURATION, CONTROL, AND CONSISTENCY 

Similarly, it is easier to control the architectural data elements using the proposed 
methodology, especially compared with the current practices of today. Configuration control of 
architectural elements can be built into the database design, only allowing certain users to make 
certain types of changes and allowing the architects to retain ownership of their perspective data 
elements. Also, disparate architectural efforts often face the problem of different architects 
using different language to capture requirements and lE Rs. By incorporating a centra liz ed 
database into the domain’s architectural efforts, key data elements, such as activities and 
systems—those elements upon which the majority of the architecture is based—can be 
accessed through picklists or other uneditable user interfaces, forcing the architecture to be 
based to a common language or data standard. 

Furthermore, because the architectural elements are contained in only one location, 
many problems with data consistency are alleviated. A high level of consistency is required 
within any architecture to maintain usability. As discussed previously, current architectural 
efforts lack the visibility between efforts to ensure that IERs are documented by both endpoints, 
i.e. if TBMCS lists an TH R with GCCS, does GCCS list the same IER in reverse. However, 
using the outlined approach, this level of consistency is maintained by forcing all architectural 
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efforts into a common database, thus providing a structured methodology for preventing these 
kinds of oversights. 

C. INTEGRATING MULTIPLE ARCHITECTURES 

A data-driven approach to architecture design facilitates the integration of multiple 
architectures much faster than any picture-based efforts. As seen in the maintainability example, 
a single activity touched nearly 150 other architectural data elements. In a database, it is a fairly 
simple task to discover which other objects and associations were tied to that task. In picture- 
based architectures, there are no such mappings. Every element of the subject architecture 
would have to be examined during every integration effort to see where the links and 
dependencies lie. 

D. MULTIPLE VIEW CAPABILITIES 

By focusing on the data rather than specific views of the data, the proposed 
methodology leaves considerable flexibility in how the data will be presented to the end user. 
There exist a variety of tools that can provide access to the data in tabular, database, or even 
picture format. Being able to view architectural elements in picture format is a surprisingly 
effective style for representing the data—as long as the data drives the picture and not the other 
way around. Several modem architectural tools use a graphic user interface to dynamically 
generate architectural drawings based on the underlying data. Furthermore, users can 
manipulate the drawings and the changes are passed down to the core data elements. This 
approach combines the simplicity of the pictures with the strength of the relational database and 
is an excellent approach to architectural development. 

1. Role-Centric vs. System-Centric 

The most obvious viewing benefit introduced with this approach is the ability to view the 
architecture data from either a role-centric or system-centric perspective. Functional area 
experts may want to view how different systems have been tasked to meet the needs of his 
functional area while system developers may want to view how their particular systems have 
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been tasked across the many functional areas. These two ‘architectures’ are built off the same 
set of underlying data. And, therefore, the data can be viewed in any manner the user wishes. 

Depending on the power of the tools used to interface with the database, a user could 
choose to view the interactions between all Command and Control systems assigned to any 
functional area, or how a specific system, like GCCS, fits into the functional area of Focused 
Logistics. Similarly, a user could view how the Air Superiority functional area has been 
developed; or rather view just the Navy components of Theater Air and Missile Defense. A 
data-driven approach does not constrain the users ability to present the information contained in 
the architecture, and therefore, is one of the greatest benefits of this methodology. 

2. “Roll-Up”/Zoom In/Zoom Out 

Storing architectural information within a database also allows the user to choose the 
level of detail at which to view the architecture. As the GCCS program manager, I might want 
to see how GCCS is expected to interact with other systems in the many different functional 
areas. Using a data-driven approach, I could then drill down into the GCCS system itself to 
view how each of the components of GCCS come together to meet these requirements. The 
level of detail to be viewed would only be constrained by the amount of information that had 
been put into the architecture. And, if GCCS were part of a bigger system, like the Air 
Operations Center, I could ‘zoom out’ to see how my system fit into the bigger picture of the 
functional area. 

3. Time-Phasing 

The time-phasing of requirements and capabilities within the architecture enables 
another viewing benefit—the ability to view the architectural elements at any date in time. As a 
functional area architect, I could view how systems could best support my functional area today, 
in 2005, 2010, and 2020 by merely selecting the date I wanted to see. The data elements 
would then be extracted based on the time attributes they previously had been assigned. 
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Current architectural efforts often discuss the difference between “as-is” and “to-be” 
architectures. Unfortunately, because of the discussed shortcomings in the process, these 
become separate architecture efforts, each demonstrating a single snapshot in time. As soon as 
the “as-is” architecture is developed, it is out of date because system capabilities have changed. 
And the “to-be” architecture can only be developed to a single future date, often 5 or 10 years 
in the future. But neither provides the flexibility to ask, “How would the architecture look 
somewhere in between?” A data-driven approach provides that capability. 
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VI. CLOSING COMMENTS 


A. RECOMMENDATIONS 

The proposed methodologies have a number of applications: defense, commercial and 
academic; systems engineering, integration, and development; software design, integration, and 
development. The author recommends their use in any environment which employs distributed 
systems and transactions to achieve a common purpose. 

It is recognized that in many communities, the Department of Defense in particular, 
changing current processes to incorporate some of these methods is a cumbersome effort. 
However, the DoD cannot afford to continually throw money at disparate architecture efforts 
that have no chance of enabling a state of interoperability, as they are uncoordinated, 
inconsistent and unavailable to the other stakeholders whose participation is vital in a system’s 
development. Only through strong leadership, and a ‘top-down’ enforcement of disciplined 
architectural methods will interoperability be achieved. 

B. CONCLUSIONS 

The use of enterprise architecture techniques in the planning and requirements phases of 
system development can facilitate system-to-system and software-to-software interoperability. 
In order to realize the benefits of the architectural methodologies, a structured framework for 
implementing and maintaining the architecture is required. It must be fully integrated into each 
stakeholder’s processes before full benefit can be real iz ed. The time and resources saved using 
an integrated, data-driven architectural approach will create a more efficient environment for the 
development of systems and their requirements, and will enable a state of system interoperability 
to be achieved and maintained indefinitely. 
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APPENDIX A 



Figure A-l. Proposed Architecture Data Model 
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APPENDIX B 


The following figure shows a high-level overview of the C4ISR Core Architecture Data 


Model: 



Figure B-l: C4ISR Core Architecture Data Model 


As discussed previously, efforts to establish a common data framework are key to 
establishing a dynamic enterprise architecture. Depending on the size and nature of the 
enterprise, it is likely that pieces of the architecture will be worked in relative anonymity to the 
other pieces; and so, establishing a common data model is vital to future efforts to integrate 
those pieces into a single architecture. 
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In constructing the proposed methodology, careful steps were taken to ensure the new 
data model was compliant with the CADM. Current DoD efforts are already adhering to the 
guidelines established in the CADM, and it is important that any new methodologies adhere to 
these same basic principles, to promote reuse of previous architectural efforts. The following 
table shows the mapping of the proposed architectural data model elements to the C4ISR Core 
Architecture Data Model elements. 


Proposed Data Model Element Corresponding CADM Element 


Role 

Node 

Activity 

Proce s s- Activity/Task 4 

Information Exchange Requirement 

Exchange Need-Line-IER 5 

System 

System 

System Information Exchange Capability 

N/A 

System Activity 

System- Process- Activity 

System Information Exchange Requirement 

Information- Exchange - Matrix- Element 6 


Table B-l - CADM Data Model Comparison 


4 The CADM confuses the activity modeling aspects of architectures by establishing two types of 
“operationally-oriented” activities: Process-Activity and Task. While it claims that various instances of 
Process-Activity in an activity-model are related by specifying information flows between pairs of the 
Process-Activities, it establishes that an Information Exchange Need-Line-IER goes between two tasks. 

This suggests that in order to establish an operational connection between two nodes, one must define the 
tasks and the need to exchange information between them; and then separately model these information 
flows using the Process-Activity-Model. This doubles the work of the enterprise architect. The proposed 
methodology simplifies this construct by suggesting tasks may also be modeled using the IDEFO processes; 
and, therefore, there remains no need to maintain process-activity as a separate entity. As it is, the 
proposed “Activity” set can be modeled using either data element. 

5 Exchange Need-Line-IER is the association between an Exchange Need-Line-Requirement (a need for a 
physical connection between two nodes) and an Information Exchange Requirement (a logical need for 
information flow between two nodes) and represents the joining of the information requirement with the 
physical connection requirement. In the proposed data model, we simplify this concept by assuming that in 
all cases where there is a logical node for information to flow, there exists a physical need, thus eliminating 
the need to further define these two concepts separately from their joining. 

6 This relationship is overcomplicated in the CADM. The Information-Exchange-Matrix requires the 
architect to associate the original Exchange-Need-Line, the IER, the System, the Process-Activity, the Task, 
and the System-Process-Activity to make the connection between a System and an Exchange-Need-Line - 
IER. This relationship is greatly simplified in the proposed methodology by associating two System- 
Process-Activities (System Activity) with an Exchange-Need-Line IER (IER,) which already bring with them 
the other information elements. 
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As demonstrated, the data model for the proposed methodology is generally CADM- 
compliant, and in many ways greatly simplifies the existing model by reuse of architectural 
elements. The primary reason for the vast simplification is that the proposed methodology 
focuses on enterprise architectures in how they can be used to capture interoperability 
requirements. There are a multitude of other valid purposes for architectures which are not to 
be understated, but do not apply to the issue of interoperability. The CADM aims to provide a 
data model which applies to all DoD architecture efforts, and, therefore, contains many elements 
not applicable to this work. 

The proposed methodology introduces an additional concept beyond the CADM—the 
System Inf ormation Exchange Capability. Although the CADM supports the concept of a 
Capability, and even a System- Capability, this object cannot easily be linked to an Information 
Exchange Requirement, Exchange-Need-Line or Exchange-Need-Line-IER. The concept of 
differentiating between an information exchange requirement and information exchange 
capability is fundamental for the proposed architectural process to be used by system and 
software engineers. The ability to view current information exchange capabilities versus future 
operational information exchange requirements is an absolutely vital element of using the 
proposed methodology to levy future information exchange requirements on existing and 
emerging systems. The current CADM construct does allow for this kin d of analysis (i.e. it 
provides for all the necessary data elements to make this kin d of assessment); but it does not 
bring them together at any fused location, either by matrix or data element. 
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APPENDIX C 


Hie emergence of AP-233 as an ISO standard for systems engineering data exchange is an 
opportunity to show the proposed methodologies are in line with current industry trends. The 
figure below shows the overall structure for AP-233. All the figures found in this Appendix 
were found in “The technical data coverage of the emerging AP-233 STEP Standard and its use 
in virtual enterprises,” by Julian Johnson, Erik Herzog, and Michael Giblin, three of the founders 
of AP-233. 
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Figure 4.1: Working Draft #5 Overview 
Figure C-l. AP-233 Data Model Overview [17] 


Because AP-233 is still in draft, much detail on exact specifications is not available. 
Additionally, a complete comparison of the two data models could not be accomplished due its 


81 














‘working’ status. However, the overview shows many similarities to the proposed architecture 
data model. 

First, it recognizes the need for an Object-Oriented Representation, both within the data 
model itself, and also as the data elements are implemented within the many tools of the Systems 
Engineering community. Second, AP-233 accounts for the fundamental differences between 
requirements and capabilities, in that it implements both a functional architecture and a 
physical architecture. Furthermore, it allows both functions and requirements to be mapped 
to the physical architecture , thus providing associations similar to the proposed system 
function and system requirement. Further detail on some of these relationships is available. 

Figure C-2. Allocating Requirements to Systems [17] 


Verson management 
information suppressed 



Figure C-2 shows the relationship between systems and requirements, showing the AP-233 
also supports the concept of associating systems to requirements as a separate entity they refer 
to as a Requirement_system_viewrelationship , but is similar in construct to the proposed 
system requirement. That is, it is an association between an instance of a requirement and an 
instance of a system. Furthermore, AP-233 allows for systems to be decomposed into their 
components systems, as seen in Figure C-3. 
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Figure C-4, which focuses on activities, shows many similarities to the proposed 
architectural data model. First, it begins the activity-modeling example with the concept of a 
Work_order, which appears to be similar to a functional area—a collection of 



Figure C-3. System Decomposition [17] 


activities that together complete a task. Second, it supports the concept of roles—groups 
of activities that come together to achieve a common purpose. Here seen in the block 
Engineering_process_activity_element_ assignment , where activities (and NOT 
requirements) are assigned to roles. Third, it recognizes that requirements are instantiations of 
activities as assigned to systems. This is one of the basic tenets of the proposed architectural 
model, and is supported in the AP-233 draft. Finally, as discussed in the previous paragraph, 
these requirements are assigned to systems. 

There are clearly some aspects of AP-233 that are not fully accounted for. One striking 
difference between the proposed model and AP-233 is that AP-233 does not appear to 
support the concept of activity decomposition. However, it is unclear due to its draft state if this 
is an unsupported concept, or merely one that has not been fully architected yet. 
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Regardless, there are sufficient similarities between the two efforts to show that both have 
taken a similar approach to data modeling. It is possible that future efforts in enterprise 
architecting could use the AP-233 as its data standard. 
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Figure C-4. Activity Modeling Example [171 
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